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
>
