Make the timezone dropdown a location dropdown
Background
When displaying dates with the DateTime macro, MoinMoin interprets the user time zone to display the time in the proper locale. However, that's not really clear in the display itself. No timezone information is available in the list of formats in the user preferences.
Rationale
The time display should be unambiguous, even if it's not in UTC. To display the timezone properly, the TZ environment needs to be set correctly. One of the best way of doing that is to use the UNIX zoneinfo database which gives out a location-based listing of all available timezones. We would get automatic daylight saving adjustments as a bonus. Of course, the old method would remain for those systems who do not have the zoneinfo database.
Implementation
The wrong way
First, without zoneinfo, things look like this in python:
>>> import os
>>> import time
>>> os.environ['TZ'] = 'EST+05EDT,M4.1.0,M10.5.0'
>>> time.tzset()
>>> time.strftime('%X %x %z %Z')
'15:10:50 12/23/05 -0500 EST'or another example:
>>> os.environ['TZ'] = 'AEST-10AEDT-11,M10.5.0,M3.5.0'
>>> time.tzset()
>>> time.strftime('%X %x %Z %z')
'07:11:19 12/24/05 AEDT +1100'That's rather complicated. We don't want that. The old method of tz_offset is better than that.
The right way
However, UNIX systems have the zoneinfo database. Let's try that instead:
>>> os.environ['TZ'] = 'EST'
>>> time.tzset()
>>> time.strftime('%X %x %Z %z')
'15:12:41 12/23/05 EST -0500'
>>> os.environ['TZ'] = 'Egypt'
>>> time.tzset()
>>> time.strftime('%X %x %Z %z')
'22:12:55 12/23/05 EET +0200'
In Moin
In moin, those things are dealt with in two places: userform.py (in _tz_select() and handle_data()) and user.py (in getFormattedDate()). _tz_select() takes care of generating the form, handle_data() takes care of retrieving the choices from the user. getFormattedDate() takes care of displaying the things in the right timezone.
My immediate idea would be to add a user.location preference that would be set a string that would be a valid zoneinfo entry. The list made in tz_select() would be created from the one usually stored in /usr/share/zoneinfo/zone.tab (at least on FreeBSD).
The tz_offset would be computed and set for backward compatibility. The getFormattedDate() would *try* to display the timezone, based on wether or not the user has a .location preference set. Some locking would be necessary if a TZ environment change is necessary.
I'll try to make a patch if i find the time, but it will probably be valid only for 1.3... -- TheAnarcat 2005-12-23 20:34:30
- .. which will be a good reason for not merging it because we might not have the time to fit it to 1.5
Note that the code needs to be compatible with Windows as well, there should be libraries that are compatible, though.
Dealing with zoneinfo
Having done a lot of timezone-aware applications, I like the zoneinfo approach a lot. You may want to check out the PyTZ project.
Homepage: http://pytz.sourceforge.net/
Project page: http://sourceforge.net/projects/pytz/
It takes the standard zoneinfo databases (as used under Unix) and compiles it all into a standard and portable Python module. Thus it would be portable to Windows and elsewhere. -- DeronMeranda 2006-01-12 21:15:03
That project has 3 strange bugs open and there is not even a comment from the developer. No good indication for using it. -- ThomasWaldmann 2006-01-15 14:00:16
I looked at the code. And I deleted it again. I don't think it is worth adding 3 MB of code, distributed to hundreds of files (and i18n for all location names is not included!) to get this feature. -- ThomasWaldmann 2006-01-15 14:35:59
... hmm... does that mean we should altogether reject the feature? As things stand now, the timestamps become very confusing very quickly, any way we can fix that without using that 3MB library? -- TheAnarcat 2009-04-13 18:22:27
If you know something else, that is small, pretty and doing the job, we are open to suggestions. The problem is that time zone calculation is a real mess and changed in history often. -- ThomasWaldmann 2009-04-13 20:11:33
There is also python-dateutil. I've been looking at time zone-related stuff for EventAggregator and it's possible that what pytz and python-dateutil provide is desirable: the notion of a time "regime" which can suggest the wall-clock time for any given well-defined UTC time. (I refuse to refer to things like "Europe/Oslo", for example, as a time zone, since summer and winter time behave like different zones.) -- PaulBoddie 2010-03-15 11:08:41
A time zone is generally defined as "a region that has a uniform standard time" (source: Wikipedia). Additionally, "Where daylight saving time is used, the term standard time typically refers to the time without the offset for daylight saving time." (source: Wikipedia). In other words, according to these definitions, when daylight saving time comes into effect, the actual time zone doesn't change for that region. So it would be safe to refer to "Europe/Oslo" as a time zone. -- 213.163.92.164 2015-04-07 09:41:12