pytz

Etc/GMT* zones seem to be inverted

Bug #786022 reported by Ricardo Bánffy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pytz
Won't Fix
Undecided
Unassigned

Bug Description

The time offset in GMT* zones seems to be reversed.

In [1]: import datetime, pytz

In [2]: utc = pytz.utc

In [3]: tz1 = pytz.timezone('Etc/GMT-3')

In [4]: tz2 = pytz.timezone('America/Sao_Paulo')

In [5]: datetime.datetime.now()
Out[5]: datetime.datetime(2011, 5, 20, 20, 47, 41, 506937)

In [6]: utc.localize(datetime.datetime.now()).astimezone(utc)
Out[6]: datetime.datetime(2011, 5, 20, 20, 47, 53, 159642, tzinfo=<UTC>)

In [7]: utc.localize(datetime.datetime.now()).astimezone(tz1)
Out[7]: datetime.datetime(2011, 5, 20, 23, 47, 57, 486966, tzinfo=<StaticTzInfo 'Etc/GMT-3'>)

In [8]: utc.localize(datetime.datetime.now()).astimezone(tz2)
Out[8]: datetime.datetime(2011, 5, 20, 17, 47, 59, 847032, tzinfo=<DstTzInfo 'America/Sao_Paulo' BRT-1 day, 21:00:00 STD>)

In [9]: tz3 = pytz.timezone('Etc/GMT+3')

In [10]: utc.localize(datetime.datetime.now()).astimezone(tz3)
Out[10]: datetime.datetime(2011, 5, 20, 17, 49, 41, 809435, tzinfo=<StaticTzInfo 'Etc/GMT+3'>)

Revision history for this message
Ricardo Bánffy (rbanffy) wrote :

A very easy way to demonstrate (and to test):

In [19]: pytz.timezone('Etc/GMT-3').utcoffset(None)
Out[19]: datetime.timedelta(0, 10800)

In [20]: pytz.timezone('Etc/GMT+3').utcoffset(None)
Out[20]: datetime.timedelta(-1, 75600)

Both results are the opposite of what they should be. GMT+ zones should never point to a previous time.

I am familiarizing myself with the codebase, maybe I will be able to offer a patch.

Revision history for this message
Stuart Bishop (stub) wrote :

This is a historical artifact with the Olson timezone database. Its been reversed like this for decades and unlikely to be changed as the Etc/* timezones are all deprecated and just historical.

Changed in pytz:
status: New → Won't Fix
Revision history for this message
Ricardo Bánffy (rbanffy) wrote :

Thanks, Suart.

While I agree there are better ways to represent real timezones, etc timezones are useful for testing (which is how I found the problem) and despite the errors in the Olson database, pytz should provide a correct offset unless the incorrect behavior is relied upon by legacy code, something I believe not be the case. I understand the wish not to insert code to compensate for an incorrect tz table, but, since it's very unlikely to be corrected there, the fix on pytz's side would end up solving the problem forever.

We could, at least, add a deprecation warning telling people that "Etc timezones are deprecated and the Olson tz database presents them incorrectly"

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.