You are definitely right on all points, can't believe I overlooked that. I just saw the package difference and the change in default behavior and wrongfully jumped to conclusions. My apologies and thank you for your help
On Thu, Sep 15, 2016 at 7:14 PM Aurelien Jarno <aurel...@aurel32.net> wrote: > 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 >