[tz] Incorrect Time Zone Data for American/Grand_Turk

[Brian Inglis]

On 2018-07-24 09:00, Robert MacGrogan wrote:
> On Tue, Jul 24, 2018 at 10:29 AM, Paul Eggert wrote:
>> Robert MacGrogan wrote:
>>> Turks and Caicos switched to supporting daylight savings time in March of
>>> 2018. So in summer the correct time for America/Ground_Turk should be GMT
>>> -4 and then back to GMT -5 again in the fall. 
>>> The current database returns times for summer of 2018 as GMT -5, which is 
>>> incorrect. 
>> I'm not seeing that; the behavior I'm seeing is the behavior that you say is 
>> correct. For example, "zdump -Vc 2018,2019 America/Grand_Turk" outputs:
>> 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
> I'm definitely seeing incorrect behavior when I test dates in July of 2018.
> FYI I changed line 3426 in the northamerica file to the following:>			-4:00	US	AST	2018 Mar 11 3:00> I can't claim to fully understand the data
structures in this file but this
> seems to have fixed the issue for me.
For current and future years, but if you run e.g.:

	$ zdump -Vc 2015,2018 America/Grand_Turk

you should see times and offsets changing to and from DST according to US rules,
with both STD and DST times labelled AST, between 2015 and 2018: the function of
the "-" was to switch off DST rules.
This shows that all dates and times on the system recorded between 2015 and 2018
will be displayed off by an hour during US DST periods, and some previously
valid local time input may be treated as invalid, or shifted by an hour if stored.

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