pytz and Etc/GMT-5

Question

I'm having trouble understanding the conversion between the "Etc/GMT-5" timezone and UTC in pytz.

>>> dt = datetime(2009, 9, 9, 10, 0) # September 9 2009, 10:00
>>> gmt_5 = pytz.timezone("Etc/GMT-5")
>>> gmt_5.localize(dt)
datetime.datetime(2009, 9, 9, 10, 0, tzinfo=<StaticTzInfo 'Etc/GMT-5'>)

Everything is fine so far, but then I try to convert that to UTC:

>>> gmt_5.localize(dt).astimezone(pytz.utc)
datetime.datetime(2009, 9, 9, 5, 0, tzinfo=<UTC>)

So to me it seems that when converting from 10:00 in GMT-5 to UTC I get 05:00? I would expect pytz to give me 15:00 instead.

What am I missing?

EDIT: I have confirmed that timezone conversion for the US/Eastern timezone works just as I'd expect:

>>> eastern = pytz.timezone("US/Eastern")
>>> eastern.localize(dt)
datetime.datetime(2009, 9, 9, 10, 0, tzinfo=...) # Too long
>>> pytz.utc.normalize(eastern.localize(dt).astimezone(pytz.utc))
datetime.datetime(2009, 9, 9, 14, 0, tzinfo=<UTC>)

EDIT 2: I have confirmed that when I use Etc/GMT+5 I get 15:00, which is what I'd expect to get from Etc/GMT-5. Is this a pytz bug?

Triplett

Answer 1

This is apparently a POSIX thing. From Wikipedia:

In order to conform with the POSIX style, those zones beginning with "Etc/GMT" have their sign reversed from what most people expect. In this style, zones west of GMT have a positive sign and those east have a negative sign.

Kamchatka

You beat my own answer by 23 seconds! :) – Triplett

thank you for confirming that this is by design - using it as a workaround with the idea that it could change was driving me crazy – Automaton

Answer 2

This bug report explains this behavior. Apparently they know that it is all inverted, but that's because anything else would break compatibility.

Triplett

Answer 3

Why is this reversal taking place?

The behavior you're observing is because of the way the "Etc/GMT-5" timezone is defined in the IANA Time Zone Database. The "Etc/GMT-5" timezone IS AN INVERTED REPRESENTATION OF THE UTC OFFSET, which means it represents a time zone with a fixed offset of -5 hours ahead of UTC.

In the "Etc/GMT-5" timezone, a positive offset means a time behind UTC, and a negative offset means a time ahead of UTC. This is the opposite of the conventional time zone representation.

When you localize the datetime dt using the "Etc/GMT-5" timezone, you are setting it to 10:00 with a UTC offset of -5 hours. So, in the "Etc/GMT-5" timezone, 10:00 is equivalent to UTC time 15:00 (10:00 - 5 hours).

However, when you convert this localized time to UTC using the astimezone (pytz.timezone("UTC")) method, it takes the UTC offset of the original time zone into account. Since the "Etc/GMT-5" timezone has a negative offset of -5 hours, converting it to UTC effectively adds 5 hours to the original time. So, 10:00 in "Etc/GMT-5" becomes 05:00 in UTC (10:00 + 5 hours).

This BEHAVIOR IS CONSISTENT WITH THE WAY TIME ZONES ARE DEFINED IN THE IANA TIME ZONE DATABASE, where "Etc/GMT" zones have inverted offsets.

Solution/Workaround

If you need to convert a datetime from GMT-5 to UTC 0, you can use the pytz library to handle the time zone conversions.

THE STRATEGY CONSISTS OF INVERTING THE SIGN OF YOUR GMT, that is, if you want "GMT-5" then you will enter "GMT+5" ("Etc/GMT+5") for the datetime timezone you want to convert.

Here's how you can do it...

from datetime import datetime
import pytz


# Create a datetime object with a GMT-5 timezone.
gmt_minus_5_timezone = pytz.timezone("Etc/GMT+5")
gmt_minus_5_datetime = gmt_minus_5_timezone.localize(datetime(2023, 8, 1, 12, 0, 0))

# Convert the GMT-5 datetime to UTC (UTC+0).
utc_timezone = pytz.timezone("UTC")
utc_datetime = gmt_minus_5_datetime.astimezone(utc_timezone)

print(gmt_minus_5_datetime)
# Output: 2023-08-01 12:00:00-05:00 (Notice the -05:00, which represents GMT-5).

print(utc_datetime)
# Output: 2023-08-01 17:00:00+00:00 (The converted datetime in UTC, which is UTC+0).

Thanks! 😎

Conjoined