Timezone setting lacks daylight savings and offset timezones.

[tracticket@…]

The local timezone setting lacks support for daylight savings time and offset timezones which are used all over the world. It would be better to set this to use actual timezone notation from published timezone data which shouild be very easy to impliment and foolproof.

[anonymous]

s/.5/offset/ as there are countries that use 15 min intervals.

[jonas]

Trac tries to use ​pytz if available which provides > 500 time zone definitions. If that python module isn't available Trac falls back on a built in implementation which only supports a couple of static time zones (GMT +- X).

So I guess you don't have pytz installed, please reopen this ticket if I've misunderstood something.

[anonymous]

Yeah, I see that now on the site I looked earlier but couldn't find it (searching for pytz brings it up, though.).

However, daylight savings calculation is still broken, the main webpage for pytz offers some insight for this:

• Note that if you perform date arithmetic on local times that cross DST boundaries, the results may be in an incorrect timezone (ie. subtract 1 minute from 2002-10-27 1:00 EST and you get 2002-10-27 0:59 EST instead of the correct 2002-10-27 1:59 EDT). This cannot be resolved without modifying the Python datetime implementation. However, these tzinfo classes provide a normalize() method which allows you to correct these values.

[ThurnerRupert]

there is wiki:0.11/TracInstall, and jonas also stated the link to pytz. and a mailing list ...

[anonymous]

Did you even read anything of what I said? I know about the tracinstall page (read the first line).

Also you did not mention anything about the daylight savings time problem. I cannot get trac to recognise any daylight savings time timezones. Please see my previous comment:ticket:5895:3. The problem is in _trac_ and is a bug, not a support issue the required conversion to support the workaround for python's datetime implimentation is not included in source:trunk/trac/util/datefmt.py@5754​

To be clear, i have installed pytz, i can see timezones it's the ​Daylight savings time that is not working for the reason I stated above and in my previous comment:ticket:5895:3

[jonas]

I'm not quite sure I understand the problem. Are you talking about the DST corner case you cited from the pytz website or something else.

Can you give a more details about how the DST calculation in Trac is broken and instructions on how to reproduce it.

[anonymous]

Here's an example that I should have provided earlier, in hindsight I wasn't being very clear sorry about that. The actual time seems be correct in every case I've checked. It's the actual tag that's wrong it's displaying the standard time tag when It's actually in DST mode.

Setting the timezone to Canada/Eastern? results in:

In your time zone EST, this would be displayed as 16:40:29Z-0400.

This should read

In your time zone EDT, this would be displayed as 16:40:29Z-0400.
                  ^^^

The actual time displayed is correct it may seem like a minor thing but it gets extremely confusing real fast when setting to timezones you're not used to in which case you're not sure which is correct, the timezone or the actual time.

Some other examples include PST/PDT (US/Pacific) and MST/MDT (US/Mountain), the other Canadian values are really wrong but this has been brought to the attention of the pytz folks already.

[cobwebsmasher@…]

Since you guys seem to be deep into timezone theory here, I'm curious if either of you know how timezone information was handled in trac before 0.11? Specifically 0.9.6 era, there are a couple of old TracIni hits on Google that make reference to a default_timezone field in trac.ini --- is this a lie or a stub that never got used? I've been noshing through the codebase of 0.9.6 and can't locate where that value would ever get used.

[ThurnerRupert]

are you really sure this is a trac bug? or it is more a pytz bug and should be filed there?

[cboos]

It's not a pytz bug, we're simply ignoring the DST so far.

[jruigrok]

I think it is related to pytz: ​https://bugs.launchpad.net/pytz/+bug/148307

[rblank]

Replying to jruigrok:

I think it is related to pytz

It does indeed seem that tzinfo.tzname(dt) ignores its parameter when tzinfo comes from pytz. However, even if it didn't, the documentation of datetime specifies that:

These methods are called by a datetime or time object, in response to their methods of the same names. A datetime object passes itself as the argument, and a time object passes None as the argument. A tzinfo subclass's methods should therefore be prepared to accept a dt argument of None, or of class datetime.

When None is passed, it's up to the class designer to decide the best response.

Therefore, passing None to tzinfo.tzname() will not work as expected in the date/time preference panel. The following should fix the problem, when pyzt will be fixed as well:

trac/prefs/templates/prefs_datetime.html

@@ -28 +28 @@
       <p class="hint" py:with="now = datetime.now(utc)">
         Example: The current time is <strong>${format_time(now, 'iso8601', tzinfo=utc)}</strong> (UTC).
         <br />
-        In ${session_tzname and 'your' or 'the Default'} time zone ${session_tzname and ' ' + selected_tz.tzname(None) or ''}, this would be displayed as
+        In ${session_tzname and 'your' or 'the Default'} time zone ${session_tzname and ' ' + now.replace(tzinfo=selected_tz).tzname() or ''}, this would be displayed as
         <strong>${format_time(now, 'iso8601', tzinfo=(session_tzname and selected_tz or localtz))}</strong>.
       </p>
 

[jomae]

If a user selects Canada/Eastern timezone, pytz.exceptions.NonExistentTimeError occurs in prefs/datetime page at DST starting (e.g. 2011-03-13 02:00).

>>> from trac.util.datefmt import timezone
>>> from datetime import datetime
>>> from trac.util.datefmt import utc
>>>
>>> selected_tz = timezone('Canada/Eastern')
>>> selected_tz.tzname(datetime(2011, 3, 13, 2, 0, 0))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site-packages/pytz/tzinfo.py", line 478, in tzname
    dt = self.localize(dt, is_dst)
  File "/usr/lib/python2.4/site-packages/pytz/tzinfo.py", line 322, in localize
    raise NonExistentTimeError(dt)
pytz.exceptions.NonExistentTimeError: 2011-03-13 02:00:00

I think that we should use normalize method for converting timezone, if a user selects pytz timezone. See ​http://pytz.sourceforge.net/#localized-times-and-date-arithmetic.

The patch has been committed in my branch [7828/jomae].

[rblank]

I have only little knowledge of timezones, so I can't really comment on the correctness of the patch. As long as you know what you are doing, please apply ;)

[jomae]

Ok. The patch has been committed in [10844]. The normalize method has been already indicated on the comment:3.

[cboos]

One little improvement could be to add a no-op normalize() to FixedOffset and LocalTimezone instead of checking for the existence of the method (hasattr(selected_tz, 'normalize')).

[jomae]

Replying to cboos:

One little improvement could be to add a no-op normalize() to FixedOffset and LocalTimezone instead of checking for the existence of the method (hasattr(selected_tz, 'normalize')).

Good suggestion, thanks. It would be simple.

In [10846], adds the method which is similar to StaticTzInfo.normalize (at pytz.tzinfo) and removes the checking.