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.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
_______________________________________________ Moin-user mailing list Moin-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/moin-user
