tz_convert error when using GMT timezones

[GiorgioBalestrieri]

Code Sample

dates = pd.date_range(start=pd.datetime(2018,1,1), periods=4, freq='h', tz='UTC')

print(dates)
print(dates.tz_convert('Etc/GMT+1'))
print(dates.tz_convert('Europe/Rome'))

output:

DatetimeIndex(['2018-01-01 00:00:00+00:00', '2018-01-01 01:00:00+00:00',
               '2018-01-01 02:00:00+00:00', '2018-01-01 03:00:00+00:00'],
              dtype='datetime64[ns, UTC]', freq='H')
DatetimeIndex(['2017-12-31 23:00:00-01:00', '2018-01-01 00:00:00-01:00',
               '2018-01-01 01:00:00-01:00', '2018-01-01 02:00:00-01:00'],
              dtype='datetime64[ns, Etc/GMT+1]', freq='H')
DatetimeIndex(['2018-01-01 01:00:00+01:00', '2018-01-01 02:00:00+01:00',
               '2018-01-01 03:00:00+01:00', '2018-01-01 04:00:00+01:00'],
              dtype='datetime64[ns, Europe/Rome]', freq='H')

Problem description

Converting midnight UTC ('2018-01-01 00:00:00+00:00') to GMT+1 (Etc/GMT+1) should return 1 AM ('2018-01-01 01:00:00+01:00'), but returns 11 PM ('2017-12-31 23:00:00-01:00'), which is one hour behind instead of one hour ahead.

Using Europe/Rome returns the correct output, so I tend to think this is specifically related to time zones using GMT as reference.

Looking at the outputs, it seems the error might actually come from the numpy datetime64 type, which has -01:00 as timezone indicator for GMT+1.

Maybe I am missing something, since it is very odd this hasn't been spotted before.

Output of pd.show_versions()

INSTALLED VERSIONS

commit: None
python: 3.6.5.final.0
python-bits: 64
OS: Windows
OS-release: 10
machine: AMD64
processor: Intel64 Family 6 Model 78 Stepping 3, GenuineIntel
byteorder: little
LC_ALL: None
LANG: None
LOCALE: None.None

pandas: 0.23.0
pytest: 3.0.7
pip: 10.0.1
setuptools: 38.5.1
Cython: 0.25.2
numpy: 1.13.3
scipy: 1.0.0
pyarrow: None
xarray: None
IPython: 5.3.0
sphinx: 1.5.6
patsy: 0.4.1
dateutil: 2.6.0
pytz: 2017.2
blosc: None
bottleneck: 1.2.1
tables: 3.4.2
numexpr: 2.6.4
feather: None
matplotlib: 2.2.0
openpyxl: 2.4.7
xlrd: 1.0.0
xlwt: 1.2.0
xlsxwriter: 0.9.6
lxml: 3.7.3
bs4: 4.6.0
html5lib: 0.999
sqlalchemy: 1.1.9
pymysql: None
psycopg2: None
jinja2: 2.9.6
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None

[mroeschke]

We use pytz under the hood to parse tz strings, and pytz.timezone('Etc/GMT+1') has a utcoffset of -1 hour

In [4]: pytz.timezone('Etc/GMT+1')._utcoffset == timedelta(hours=-1)
Out[4]: True

So from Pandas point of view this is correct. If you believe this is an issue with pytz, you should raise it there.

[GiorgioBalestrieri]

Ok, thank you. Here is a link to the bug report https://bugs.launchpad.net/pytz/+bug/1777308

[GiorgioBalestrieri]

Hi,

the issue has been open for 10 days now on the pytz tracker, with no response.
Since they don't seem very responsive, I think it would be great if someone could confirm/reproduce the issue and add a warning.
It's not a huge deal but it can lead to significant errors in numerical results and plots which are extremely difficult to spot.

[mroeschke]

Unfortunately it seems that Etc/GMT is a legacy format (and hence not supported).

https://stackoverflow.com/questions/23640227/how-does-gmt-ids-work-in-java-timezone/23643847#23643847

Overall these seem equivalent to a fixed tz offset, so a workaround would be convert that tz string to a pytz.FixedOffset.

In [1]: dates = pd.date_range(start=pd.datetime(2018,1,1), periods=4, freq='h',
   ...: tz='UTC')

In [3]: dates.tz_convert(pytz.FixedOffset(60))
Out[3]:
DatetimeIndex(['2018-01-01 01:00:00+01:00', '2018-01-01 02:00:00+01:00',
               '2018-01-01 03:00:00+01:00', '2018-01-01 04:00:00+01:00'],
              dtype='datetime64[ns, pytz.FixedOffset(60)]', freq='H')

[GiorgioBalestrieri]

Thank you for the clarification, I wasn't aware that GMT was legacy and that it had the opposite convention, I find it very confusing.
I assume it's up to the user to figure this out then.

As a side note, I found myself using it because I was looking for a "fixed offset" timezone, i.e. without daylight saving time. Is there a better choice for that? (UTC+1 or something along these lines)

[mroeschke]

The only way to create a "fixed offset timezone" would be to create your own with the standard library's tzinfo class. Otherwise, having fixed offset timezones would end up producing imaginary times.

[jsdreim]

Late to this party, but this came up in my project as well. I have researched and detailed the cause in a reply here, but in short, the POSIX Standard specifies that GMT+X timezones refer to timezones west of GMT, contrary to General Usage. This issue arises because PyTZ interprets its input to follow the POSIX Standard, but does not take any measures to prevent output from following General Usage instead. The ultimate result is that GMT Offsets appear to be "flipped" by PyTZ.

I figured I should also make a post here so that more people will see it from Google.