Skip to content

Timestamp timezone inconsistency #8656

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
cyber42 opened this issue Oct 27, 2014 · 6 comments
Closed

Timestamp timezone inconsistency #8656

cyber42 opened this issue Oct 27, 2014 · 6 comments
Labels
Timezones Timezone data dtype

Comments

@cyber42
Copy link

cyber42 commented Oct 27, 2014

Hi,

Is this a known issue?

Time offset on 22nd of Sept should be -4 hours in New York as below:

pandas.Timestamp('2014-09-22 09:30:00-0400', tz='EST5EDT').tz_convert('EST5EDT')
Timestamp('2014-09-22 09:30:00-0400', tz='EST5EDT')

but when providing this twice (-0400 and EST4EDT), the result becomes -0500:

pandas.Timestamp('2014-09-22 09:30:00-0400', tz='EST5EDT')
Timestamp('2014-09-22 08:30:00-0500', tz='EST5EDT')

Thanks,
Mark

INSTALLED VERSIONS

commit: None
python: 2.7.6.final.0
python-bits: 64
OS: Linux
OS-release: 3.13.0-37-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_GB.UTF-8

pandas: 0.14.1
nose: 1.3.0
Cython: 0.19.2
numpy: 1.8.1
scipy: 0.13.2
statsmodels: 0.5.0
IPython: 2.0.0
sphinx: None
patsy: 0.2.1
scikits.timeseries: None
dateutil: 2.2
pytz: 2014.2
bottleneck: 0.8.0
tables: 3.0.0
numexpr: 2.3
matplotlib: 1.3.1
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml: None
bs4: None
html5lib: 0.999
httplib2: 0.8
apiclient: None
rpy2: None
sqlalchemy: None
pymysql: None
psycopg2: None

@jreback
Copy link
Contributor

jreback commented Oct 28, 2014

These all represent exactly the same time
you also have a pytz that maybe doesn't have the correct offsets (you are using 2014.2)
mine is 2014.7 the most recent.

In [10]: Timestamp('2014-09-22 08:30:00-0500', tz='EST5EDT').tz_convert('UTC')
Out[10]: Timestamp('2014-09-22 13:30:00+0000', tz='UTC')

In [11]: pandas.Timestamp('2014-09-22 09:30:00-0400', tz='EST5EDT').tz_convert('UTC')
Out[11]: Timestamp('2014-09-22 13:30:00+0000', tz='UTC')

In [12]: pandas.Timestamp('2014-09-22 09:30:00-0400')                                
Out[12]: Timestamp('2014-09-22 09:30:00-0400', tz='pytz.FixedOffset(-240)')

In [14]: pandas.Timestamp('2014-09-22 09:30:00-0400').tz_convert('UTC')
Out[14]: Timestamp('2014-09-22 13:30:00+0000', tz='UTC')

@jreback jreback added the Timezones Timezone data dtype label Oct 28, 2014
@rockg
Copy link
Contributor

rockg commented Oct 28, 2014

This works fine for me as well. So either check with pandas master or an updated pytz (although I would find the latter really hard to believe since there is nothing special with this offset).

pd.Timestamp('2014-09-22 09:30:00-0400', tz='EST5EDT')
Out[35]: Timestamp('2014-09-22 09:30:00-0400', tz='EST5EDT')

@jreback
Copy link
Contributor

jreback commented Oct 28, 2014

actually I think this was #7833 which was fixed for 0.15.0

@jreback jreback closed this as completed Oct 28, 2014
@cyber42
Copy link
Author

cyber42 commented Oct 28, 2014

Great, thanks! Didn't realize RC is the stable version now.

Yes, they both represent the right UTC time, but one of them didn't have
the rigth offset of its timezone, EST5EDT.
On 28 Oct 2014 01:38, "jreback" [email protected] wrote:

actually I think this was #7833
#7833 which was fixed for 0.15.0


Reply to this email directly or view it on GitHub
#8656 (comment).

@rockg
Copy link
Contributor

rockg commented Oct 28, 2014

I wouldn't call RC the stable version (however it is pretty stable and everything that gets merge needs to pass all the tests). v0.15.0 is the latest release and this is fixed there.

@jreback
Copy link
Contributor

jreback commented Oct 28, 2014

0.15.0 is the stable version released that week

http://pandas.pydata.org/pandas-docs/stable/whatsnew.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Timezones Timezone data dtype
Projects
None yet
Development

No branches or pull requests

3 participants