On 2016-09-14 14:15, Greg Flynn wrote: > Package: tzdata > Version: 2016f-1 > Severity: critical > Tags: newcomer > Justification: breaks unrelated software > > Dear Maintainer, > > * What led up to the situation? > Running unit tests in Python while set timezone using the string > 'America/Eastern'. > The offset was reported as UTC-4.93333333333333333333 which resulted > in > a discrepency of about 4 minutes > When running the same test on a server running Debian 8.5 with tzdata > 2016f-0+deb8u1 the same test passed > * What exactly did you do (or not do) that was effective (or ineffective)? > Changing timezone to 'EST' fixed the particular test and gave the > expected -5 offset for Standard time, but I think EST and America/Eastern > should be returning the same value
I think your expectation here is wrong, and probably also your
understanding of the python-tz library. The EST timezone has always been
at UTC-5, so it's normal it returns a UTC-5 value. On the other hand the
New York timezone has been using the LMT in the past.
In the example code you have given, the year is unspecified. You have
tried to freeze the current time, but arrow.get doesn't use the current
time for the values that are unspecified. This can be shown by running
for example:
print arrow.get('10:00:00', 'HH:mm:SS').format('YYYY')
This returns year 0001. Many softwares, including python-tz did not
handle dates before the first transition, which in the New York timezone
case corresponds to the switch from LMT to UTC-5. Therefore this
transition was kind of ignored and all dates before this transition was
returned as UTC-5. Recent version of zic (ie the one in stretch) has
duplicated the first transition at the time of the big bang so that
dates before this transition are handled correctly on all software.
That's why in stretch year 0001 is considered in LMT, while in jessie it
is considered in UTC-5.
In your case you should change your test code to include the full date
instead of using freeze_time:
arrow.get('2016-01-01 10:00:00', 'YYYY-MM-DD HH:mm:SS')
Given the above explanations, I do not believe it's a bug in tzdata, at
most it's a bug in python-tz. I therefore offer to just close this bug
if you agree.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
