[tz] Incorrect Time Zone Data for American/Grand_Turk

[Brian Inglis]

On 2018-08-02 10:23, Robert MacGrogan wrote:
> On Tue, Jul 24, 2018 at 12:56 PM, Paul Eggert wrote:
>> On 07/24/2018 08:00 AM, Robert MacGrogan wrote:
>>> I'm definitely seeing incorrect behavior when I test dates in July of
>>> 2018.
>> How exactly are you testing that? Are you using the data installed by your 
>> distributor, or the actual 2018e data?>>
>> What happens when you do this from tzdb 2018e source?
>> $ rm -fr /tmp/tz
>> $ make clean
>> $ make TOPDIR=/tmp/tz install
>> $ ./zdump -Vc 2018,2019 America/Grand_Turk
>> Here's the output that I get. If you get something different, please 
>> investigate.
>> America/Grand_Turk Sun Mar 11 06:59:59 2018 UT = Sun Mar 11 02:59:59 2018 
>> AST isdst=0 gmtoff=-14400
>> America/Grand_Turk Sun Mar 11 07:00:00 2018 UT = Sun Mar 11 03:00:00 2018 
>> EDT isdst=1 gmtoff=-14400
>> America/Grand_Turk Sun Nov 4 05:59:59 2018 UT = Sun Nov 4 01:59:59 2018 EDT
>> isdst=1 gmtoff=-14400
>> America/Grand_Turk Sun Nov 4 06:00:00 2018 UT = Sun Nov 4 01:00:00 2018 EST
>> isdst=0 gmtoff=-18000
> Sorry, I was out of town for a bit and was unable to respond. 
> FYI, I'm using a .NET library that is backed by the time zone database.
> Specifically I'm using my own branch of this:
> https://www.nuget.org/packages/Afk.ZoneInfo/
> I installed the 2018e data myself so there is no distributor involved. I suspect
> that some will think that the problem must be in the code base. I think that's
> unlikely because the code base has not changed in years and works perfectly
> except for this one time zone.

Considering that bugs in the tz reference code are raised and fixed regularly by
the author(s), that .NET code base has probably been orphaned for years, and may
only have been tested until it worked well enough for the author's purposes, or
checked against dates returned by native Windows interfaces.

Changes made in this project are hammered by all major software vendors (see
posts about short time frames for changes), Unix distros, and other projects
using the tzdb, ensuring that all our and their their systems and utilities csan
handle all the nuances allowed by the flexible data formats (see *long* threads
about lack of restrictions in the specs). Patch authors may also do some testing
(like from -<big bang> to +<big bang>) and often data, and the maintainer has
been known to do some hammering on his own account.

> I'll see if I can run the test you suggest, but I don't currently have a Linux
> or Unix install handy and that looks like Unix to me. 

Install your selection of Linux distro using WSL from the MS Store, then run it,
log in, install package tzdata (and tzcode if available) binaries and sources,
and you can test away.

> Running my own unit tests, btw, that is not the output I get. For Sun Mar 11
> 07:00:00 2018 UT using the 2018e data I get  Sun Mar 11 02:00:00 2018 as the
> local Grand Turk time. So maybe it is a code issue. If I change line 3426 in the
> northamerica file to this:
> 
> -4:00USAST2018 Mar 11 3:00
> 
> I get the correct result.
...until November ;^>

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada