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 <> 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

Reply via email to