[Moin-user] Proper timezone support using pytz

[Max Bowsher]

Thomas Waldmann wrote:
> 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.

Neither do I, actually, which is one of the reasons I'm calling it a
"draft". I'll need to figure this out at some point (or co-opt someone
else to test that bit.)

> Maybe some small change request:
> 
> try:
>     import pytz
> except ImportError:
>     pytz = None
> 
> if pytz:
>     # pytz is there
> else:
>     # no pytz

Heh. I actually pondered doing it that way, but concluded "if
pytz_available:" was more readable / less cryptic. I don't really mind
which way we go on this.


>> 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).

How about deleting tz_offset from profiles only when they are saved with
a user-provided 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.

This all makes sense, but there is one remaining issue:

If we make Moin only optionally use pytz, what should it do when
encountering a pytz-enabled user profile when the pytz module is not
available?

(e.g., if pytz was previously installed, but is no longer installed.)

I vote that this is a corner case that is not worth putting too much
thought into, and that Moin should just revert to letting the affected
users configure their tz_offset, and using its configured default
tz_offset until they do.

Max.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/moin-user/attachments/20091103/b0cb928f/attachment.sig>