Bug#837797: tzdata: America/Eastern reports Local Mean Time by default instead of EST

2016-09-16 Thread Greg Flynn 
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.9333 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('')
>
> 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', '-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
>

Bug#837797: tzdata: America/Eastern reports Local Mean Time by default instead of EST

2016-09-15 Thread Aurelien Jarno 
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.9333 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('')

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

Bug#837797: tzdata: America/Eastern reports Local Mean Time by default instead of EST

2016-09-14 Thread Greg Flynn 
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.9333 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
   * What was the outcome of this action?
I was sad
   * What outcome did you expect instead?
-5 offset instead of -4.9333...

https://en.wikipedia.org/wiki/Local_mean_time

Here's a gist with an example:
https://gist.github.com/gregflynn/2ac90ee0c39568f2e45f33ade476df51



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.4-saddle (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0]  1.5.59

tzdata recommends no packages.

tzdata suggests no packages.

-- debconf information:
  tzdata/Zones/Antarctica:
  tzdata/Zones/Europe:
  tzdata/Zones/Australia:
* tzdata/Zones/America: New_York
  tzdata/Zones/Atlantic:
* tzdata/Zones/Etc: UTC
  tzdata/Zones/Pacific:
  tzdata/Zones/Africa:
  tzdata/Zones/Asia:
  tzdata/Zones/Arctic:
  tzdata/Zones/Indian:
* tzdata/Areas: America
  tzdata/Zones/US:
  tzdata/Zones/SystemV: