[Moin-user] Proper timezone support using pytz

[Thomas Waldmann]

Hi Max,

> I have just finished an initial draft of a patch to give MoinMoin proper
> timezone support using pytz. (http://paste.ubuntu.com/306824/)

Ah, nice. :)

I didn't try the patch (and I don't have an openid test environment
anyway), but it looks good.

Maybe some small change request:

try:
    import pytz
except ImportError:
    pytz = None

if pytz:
    # pytz is there
else:
    # no pytz


> One option would be for MoinMoin to require pytz - this has the
> advantage of making the code simpler, as it is not necessary to maintain
> parallel codepaths. Alternatively, I've currently got the patch set up
> to conditionally import pytz - but the migration corner cases, which
> I've yet to consider carefully, are more difficult this way, and I'm
> sceptical that the extra complexity is worth it.

Well, this all depends on the user profiles: if they contain settings
for the non-pytz / pytz way of doing things, moin needs to be able to
deal with them.

> Another issue is user profile migration: I'm currently assuming that
> user profiles will be left containing and using their tz_offset
> immediately after an upgrade, and when users edit their profiles, they
> will get migrated to a named timezone. but:

One of the general problems with that is: you never know when all
userprofiles will be migrated. For bigger wikis with some stale user
profiles this likely will never happen.

> 1) Do I bother writing code specifically to allow people to enter and
> save the user prefs page (to change other prefs) without setting a
> timezone? (Or just default it to UTC and hope they set it properly
> whilst they're there)

Maybe default to "not set" (None), so it will continue using tz_offset
for that case.

> 2) Do I bother considering the potential for reverse-migration (e.g. 1.9
> -> 1.8 rollback, or 1.9-with-pytz -> 1.9-without-pytz if we go the pytz
> as optional dependency route) ?

We usually do not support downgrades from a later to an earlier moin
version.

> Options would be:
> * Delete the tz_offset from user profiles when edited after upgrade. If
> you migrate back, users end up with a defaulted tz_offset.

I almost would've preferred that way, but: there will likely be
untouched userprofiles with just tz_offset (and no tz_name).

> * Keep the old tz_offset lying around unused just in case.

If pytz is present, moin should ask for tz_name and store this into user
profile.

If pytz is present and tz_name is set, moin should use this to do time
calculations, otherwise it should use tz_offset.

> * Actually make an effort to update the tz_offset using the base offset
> of the timezone when the user reconfigures their timezone. I'm not a fan
> of this, as due to DST, it'll be a lie for half of the year anyway.

Yeah, maybe not worth the effort.

Cheers,

Thomas