Edgewall Software
Modify

Opened 12 years ago

Closed 8 years ago

Last modified 8 years ago

#5895 closed defect (fixed)

Timezone setting lacks daylight savings and offset timezones.

Reported by: tracticket@… Owned by: Jun Omae
Priority: normal Milestone: 0.12.3
Component: general Version: devel
Severity: normal Keywords: timezone daylightsaving
Cc: Branch:
Release Notes:
API Changes:

Description

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.

Attachments (0)

Change History (19)

comment:1 by anonymous, 12 years ago

Summary: Timezone setting lacks daylight savings and .5 timezones.Timezone setting lacks daylight savings and offset timezones.

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

comment:2 by Jonas Borgström, 12 years ago

Resolution: worksforme
Status: newclosed

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.

comment:3 by anonymous, 12 years ago

Resolution: worksforme
Status: closedreopened

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.

comment:4 by ThurnerRupert, 12 years ago

Resolution: worksforme
Status: reopenedclosed

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

comment:5 by anonymous, 12 years ago

Resolution: worksforme
Status: closedreopened

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

comment:6 by Jonas Borgström, 12 years ago

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.

comment:7 by anonymous, 12 years ago

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.

comment:8 by cobwebsmasher@…, 12 years ago

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.

comment:9 by ThurnerRupert, 12 years ago

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

comment:10 by Christian Boos, 12 years ago

Keywords: timezone daylightsaving added
Milestone: 0.11.1
Priority: highnormal

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

comment:11 by Jeroen Ruigrok van der Werven, 12 years ago

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

in reply to:  11 comment:12 by Remy Blank, 11 years ago

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

    a b  
    2828      <p class="hint" py:with="now = datetime.now(utc)">
    2929        Example: The current time is <strong>${format_time(now, 'iso8601', tzinfo=utc)}</strong> (UTC).
    3030        <br />
    31         In ${session_tzname and 'your' or 'the Default'} time zone ${session_tzname and ' ' + selected_tz.tzname(None) or ''}, this would be displayed as
     31        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
    3232        <strong>${format_time(now, 'iso8601', tzinfo=(session_tzname and selected_tz or localtz))}</strong>.
    3333      </p>
    3434

comment:13 by Jun Omae, 8 years ago

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

comment:14 by Jun Omae, 8 years ago

Cc: Jun Omae added

comment:15 by Remy Blank, 8 years ago

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

comment:16 by Jun Omae, 8 years ago

Cc: Jun Omae removed
Milestone: next-minor-0.12.x0.12.3
Owner: changed from Jonas Borgström to Jun Omae
Status: reopenednew

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

comment:17 by Jun Omae, 8 years ago

Resolution: fixed
Status: newclosed

comment:18 by Christian Boos, 8 years ago

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

in reply to:  18 comment:19 by Jun Omae, 8 years ago

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jun Omae.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Jun Omae to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.