Incorrect Time Zone Data for American/Grand_Turk

Hi there. It looks to me like the time zone data for America/Grand_Turk is incorrect in 2018e version of the database. 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. Thank you. -- Rob MacGrogan | Director of Software Development rmacgrogan@flightbridge.com <rmacgrogan@flightbridge.com> 850-509-6158 [image: FlightBridge] <http://www.flightbridge.com/> FlightBridge, Inc. 530 Means Street, Suite 405 Atlanta, GA 30318 www.flightbridge.com

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. Thanks. On Tue, Jul 24, 2018 at 10:29 AM, Paul Eggert <eggert@cs.ucla.edu> 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
-- Rob MacGrogan | Director of Software Development rmacgrogan@flightbridge.com <rmacgrogan@flightbridge.com> 850-509-6158 [image: FlightBridge] <http://www.flightbridge.com/> FlightBridge, Inc. 530 Means Street, Suite 405 Atlanta, GA 30318 www.flightbridge.com

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

On Mon, Jul 23, 2018 at 12:48 PM, Robert MacGrogan < rmacgrogan@flightbridge.com> wrote:
It looks to me like the time zone data for America/Grand_Turk is incorrect in 2018e version of the database.
If only there was some way to get a descriptive version string from the America/Grand_Turk he is actually using. :-)

On 2018-07-24 11:47, Bradley White wrote:
On Mon, Jul 23, 2018 at 12:48 PM, Robert MacGrogan <rmacgrogan@flightbridge.com <mailto:rmacgrogan@flightbridge.com>> wrote:
It looks to me like the time zone data for America/Grand_Turk is incorrect in 2018e version of the database.
If only there was some way to get a descriptive version string from the America/Grand_Turk he is actually using.
:-)
...and find out who is distributing it with which zic selections ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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. 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. 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:00 US AST 2018 Mar 11 3:00 I get the correct result. On Tue, Jul 24, 2018 at 12:56 PM, Paul Eggert <eggert@cs.ucla.edu> 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
-- Rob MacGrogan | Director of Software Development rmacgrogan@flightbridge.com <rmacgrogan@flightbridge.com> 850-509-6158 [image: FlightBridge] <http://www.flightbridge.com/> FlightBridge, Inc. 530 Means Street, Suite 405 Atlanta, GA 30318 www.flightbridge.com

On 08/02/2018 09:23 AM, Robert MacGrogan wrote:
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
Yes, it sounds like a code issue on your end. That change to the data is definitely wrong, as it would cause America/Grand_Turk to observe DST in 2016 and 2017 (which is ahistorical) and would always abbreviate the time as "AST" even when it was Atlantic Daylight Time. My guess is that your code is getting confused by the "2018 Mar 11 3:00", and is incorrectly interpreting that timestamp as being EST instead of AST. As I recall, zic itself had problems in this area, long ago.

Thanks for your help. I'll see if I can take this up with the Ak Zone Info project. --Rob On Thu, Aug 2, 2018 at 2:11 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 08/02/2018 09:23 AM, Robert MacGrogan wrote:
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
Yes, it sounds like a code issue on your end. That change to the data is definitely wrong, as it would cause America/Grand_Turk to observe DST in 2016 and 2017 (which is ahistorical) and would always abbreviate the time as "AST" even when it was Atlantic Daylight Time.
My guess is that your code is getting confused by the "2018 Mar 11 3:00", and is incorrectly interpreting that timestamp as being EST instead of AST. As I recall, zic itself had problems in this area, long ago.
-- Rob MacGrogan | Director of Software Development rmacgrogan@flightbridge.com <rmacgrogan@flightbridge.com> 850-509-6158 [image: FlightBridge] <http://www.flightbridge.com/> FlightBridge, Inc. 530 Means Street, Suite 405 Atlanta, GA 30318 www.flightbridge.com

I hadn't come across Afk.ZoneInfo before. I'll take an action to write a tzvalidate <https://github.com/nodatime/tzvalidate> implementation for it. In the meantime, you may want to consider using my Noda Time <https://nodatime.org> project instead, which is a different .NET library that exposes IANA data. (It's far more than that, but you can use it for just that if you want.) Jon On Fri, 3 Aug 2018 at 11:52, Robert MacGrogan <rmacgrogan@flightbridge.com> wrote:
Thanks for your help. I'll see if I can take this up with the Ak Zone Info project.
--Rob
On Thu, Aug 2, 2018 at 2:11 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 08/02/2018 09:23 AM, Robert MacGrogan wrote:
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
Yes, it sounds like a code issue on your end. That change to the data is definitely wrong, as it would cause America/Grand_Turk to observe DST in 2016 and 2017 (which is ahistorical) and would always abbreviate the time as "AST" even when it was Atlantic Daylight Time.
My guess is that your code is getting confused by the "2018 Mar 11 3:00", and is incorrectly interpreting that timestamp as being EST instead of AST. As I recall, zic itself had problems in this area, long ago.
--
Rob MacGrogan | Director of Software Development rmacgrogan@flightbridge.com <rmacgrogan@flightbridge.com> 850-509-6158
[image: FlightBridge] <http://www.flightbridge.com/>
FlightBridge, Inc. 530 Means Street, Suite 405 Atlanta, GA 30318 www.flightbridge.com

Hmm. Having tried to implement tzvalidate for Afk.ZoneInfo, I've found it's too tricky to be worth the time. It doesn't provide information about daylight/standard times, it doesn't provide the name parts, and it behaves very oddly in some case. For example, my code to determine transitions got stuck in "America/Argentina/Buenos_Aires" - because multiple UTC instants end up mapping to the same local time at the end of 1998. From a brief browse of the source code, it's not clear that the DateTimeKind values of Local and Unspecified are handled correctly, either. I'd advise against using the library for now - whether that means using Noda Time or finding an alternative. (There are definitely other options around.) On Fri, 3 Aug 2018 at 11:56, Jon Skeet <skeet@pobox.com> wrote:
I hadn't come across Afk.ZoneInfo before. I'll take an action to write a tzvalidate <https://github.com/nodatime/tzvalidate> implementation for it.
In the meantime, you may want to consider using my Noda Time <https://nodatime.org> project instead, which is a different .NET library that exposes IANA data. (It's far more than that, but you can use it for just that if you want.)
Jon
On Fri, 3 Aug 2018 at 11:52, Robert MacGrogan <rmacgrogan@flightbridge.com> wrote:
Thanks for your help. I'll see if I can take this up with the Ak Zone Info project.
--Rob
On Thu, Aug 2, 2018 at 2:11 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 08/02/2018 09:23 AM, Robert MacGrogan wrote:
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
Yes, it sounds like a code issue on your end. That change to the data is definitely wrong, as it would cause America/Grand_Turk to observe DST in 2016 and 2017 (which is ahistorical) and would always abbreviate the time as "AST" even when it was Atlantic Daylight Time.
My guess is that your code is getting confused by the "2018 Mar 11 3:00", and is incorrectly interpreting that timestamp as being EST instead of AST. As I recall, zic itself had problems in this area, long ago.
--
Rob MacGrogan | Director of Software Development rmacgrogan@flightbridge.com <rmacgrogan@flightbridge.com> 850-509-6158
[image: FlightBridge] <http://www.flightbridge.com/>
FlightBridge, Inc. 530 Means Street, Suite 405 Atlanta, GA 30318 www.flightbridge.com

Date: Fri, 3 Aug 2018 13:10:15 +0100 From: Jon Skeet <skeet@pobox.com> Message-ID: <CA+5fHtL1aMO2e_oBoj4QGEHmJvYJ1-uykXDb2r4a=kVkzw+=uw@mail.gmail.com> | For example, my code to determine transitions got stuck [...] | because multiple UTC instants end up mapping to the same local time If that is a problem for your validator, then you need to fix it, as that kind of thing can easily happen, whatever the codebase is. Simply consider what would happen if Kiribati decided to swap back to the other side of the date line (revert to its previous zone offset). There would be almost an entire day of duplicated local times (some date would repeat in local time, more or less - either that or there would be an "invented" day (Feb 29 in a non-leap year or April 31 or something similar, which would cause even bigger problems.) kre

On Fri, 3 Aug 2018 at 14:41, Robert Elz <kre@munnari.oz.au> wrote:
Date: Fri, 3 Aug 2018 13:10:15 +0100 From: Jon Skeet <skeet@pobox.com> Message-ID: <CA+5fHtL1aMO2e_oBoj4QGEHmJvYJ1-uykXDb2r4a=kVkzw+= uw@mail.gmail.com>
| For example, my code to determine transitions got stuck [...] | because multiple UTC instants end up mapping to the same local time
If that is a problem for your validator, then you need to fix it, as that kind of thing can easily happen, whatever the codebase is.
To be clear, this was "subsequent ticks". (A tick is 100ns) Yes, I absolutely cope with clocks going back. There's a big difference between that and "time stops completely for a second" which is what's actually observed with the library. On further inspection, it looks like the library completely ignores sub-second precision in some cases: when you ask for the local version of (say) 1998-12-31T23:56:30.123Z in America/Argentina/Buenos_Aires it will return 1998-12-31T20:56:30.000. Even after this has been worked around there are significant issues though. Jon

Date: Fri, 3 Aug 2018 14:56:14 +0100 From: Jon Skeet <skeet@pobox.com> Message-ID: <CA+5fHt+pJv-STH8vkv9mt19U0gih5GsprPaHZiRKOqu2g3+zvw@mail.gmail.com> | To be clear, this was "subsequent ticks". (A tick is 100ns) Ah, OK, not what I expected, but ... | On further inspection, it looks like the library completely ignores | sub-second precision in some cases: when you ask for the local version of | (say) 1998-12-31T23:56:30.123Z in America/Argentina/Buenos_Aires it will | return 1998-12-31T20:56:30.000. I know nothing about Windows data types, or .NET, but you'd see the same on most unix implementations, as struct tm has nowhere to put sub-second data (nor does time_t) - code that wants to deal with this needs to dig out the fractional second, convert the rest, assign the time_t to a struct timespec (or one of the other variants of that that abound) and then add in the fraction. Doing that is rare... kre

On Fri, 3 Aug 2018 at 15:27, Robert Elz <kre@munnari.oz.au> wrote:
Date: Fri, 3 Aug 2018 14:56:14 +0100 From: Jon Skeet <skeet@pobox.com> Message-ID: < CA+5fHt+pJv-STH8vkv9mt19U0gih5GsprPaHZiRKOqu2g3+zvw@mail.gmail.com>
| To be clear, this was "subsequent ticks". (A tick is 100ns)
Ah, OK, not what I expected, but ...
| On further inspection, it looks like the library completely ignores | sub-second precision in some cases: when you ask for the local version of | (say) 1998-12-31T23:56:30.123Z in America/Argentina/Buenos_Aires it will | return 1998-12-31T20:56:30.000.
I know nothing about Windows data types, or .NET, but you'd see the same on most unix implementations, as struct tm has nowhere to put sub-second data (nor does time_t) - code that wants to deal with this needs to dig out the fractional second, convert the rest, assign the time_t to a struct timespec (or one of the other variants of that that abound) and then add in the fraction. Doing that is rare...
In .NET, I'd *absolutely* expect that to be handled. The details of the C world are irrelevant to us :) I'd expect any C API that can't respect sub-second values to make that clear in the API, probably by both accepting and returning types that only have precision of a second. Whereas DateTime (the type being used here) has 100ns granularity - and that is preserved in *most* cases as far as I can see. Goodness knows what's happening behind the scenes, to be honest. Basically, my code was detecting this as a change in UTC offset by one-tick-per-tick (if you see what I mean). So while it would eventually have produced a tzvalidate file, the file would have been enormous and contain all these bogus transitions. Jon

On 2018-08-03 07:40, Robert Elz wrote:
On Fri, 3 Aug 2018 13:10:15 +0100 Jon Skeet wrote: | For example, my code to determine transitions got stuck [...] | because multiple UTC instants end up mapping to the same local time If that is a problem for your validator, then you need to fix it, as that kind of thing can easily happen, whatever the codebase is.
To clarify here AIUI: Jon tried to write a validator for the .NET library API tried by the OP, based on the validator for his own .NET library (which presumably passes the validation), and the .NET library tried by the OP failed the validation, because it does not correctly distinguish or handle conditions common in the tzdb, as Jon described in his failure report, advising against using the .NET library tried by the OP. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Weird. I've been using it in production for years and this is the first problem I've encountered. I actually already had a to-do on my list to check out Noda so I'll bump that up in priority. Thanks. On Fri, Aug 3, 2018 at 8:10 AM, Jon Skeet <skeet@pobox.com> wrote:
Hmm. Having tried to implement tzvalidate for Afk.ZoneInfo, I've found it's too tricky to be worth the time. It doesn't provide information about daylight/standard times, it doesn't provide the name parts, and it behaves very oddly in some case. For example, my code to determine transitions got stuck in "America/Argentina/Buenos_Aires" - because multiple UTC instants end up mapping to the same local time at the end of 1998. From a brief browse of the source code, it's not clear that the DateTimeKind values of Local and Unspecified are handled correctly, either.
I'd advise against using the library for now - whether that means using Noda Time or finding an alternative. (There are definitely other options around.)
On Fri, 3 Aug 2018 at 11:56, Jon Skeet <skeet@pobox.com> wrote:
I hadn't come across Afk.ZoneInfo before. I'll take an action to write a tzvalidate <https://github.com/nodatime/tzvalidate> implementation for it.
In the meantime, you may want to consider using my Noda Time <https://nodatime.org> project instead, which is a different .NET library that exposes IANA data. (It's far more than that, but you can use it for just that if you want.)
Jon
On Fri, 3 Aug 2018 at 11:52, Robert MacGrogan < rmacgrogan@flightbridge.com> wrote:
Thanks for your help. I'll see if I can take this up with the Ak Zone Info project.
--Rob
On Thu, Aug 2, 2018 at 2:11 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 08/02/2018 09:23 AM, Robert MacGrogan wrote:
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
Yes, it sounds like a code issue on your end. That change to the data is definitely wrong, as it would cause America/Grand_Turk to observe DST in 2016 and 2017 (which is ahistorical) and would always abbreviate the time as "AST" even when it was Atlantic Daylight Time.
My guess is that your code is getting confused by the "2018 Mar 11 3:00", and is incorrectly interpreting that timestamp as being EST instead of AST. As I recall, zic itself had problems in this area, long ago.
--
Rob MacGrogan | Director of Software Development rmacgrogan@flightbridge.com <rmacgrogan@flightbridge.com> 850-509-6158
[image: FlightBridge] <http://www.flightbridge.com/>
FlightBridge, Inc. 530 Means Street, Suite 405 <https://maps.google.com/?q=530+Means+Street,+Suite+405+%C2%A0+Atlanta,+GA+30...>
Atlanta, GA 30318 <https://maps.google.com/?q=530+Means+Street,+Suite+405+%C2%A0+Atlanta,+GA+30...>
<https://maps.google.com/?q=530+Means+Street,+Suite+405+%C2%A0+Atlanta,+GA+30...> www.flightbridge.com
-- Rob MacGrogan | Director of Software Development rmacgrogan@flightbridge.com <rmacgrogan@flightbridge.com> 850-509-6158 [image: FlightBridge] <http://www.flightbridge.com/> FlightBridge, Inc. 530 Means Street, Suite 405 Atlanta, GA 30318 www.flightbridge.com

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

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

On 2018-07-23 10:48, Robert MacGrogan wrote:
It looks to me like the time zone data for America/Grand_Turk is incorrect in 2018e version of the database. 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.
Your installed time zone data may be incorrect but 2018e is correct: $ TZ=America/Grand_Turk date +%c%z%Z 2018 Jul 24 Tue 10:31:25-0400EDT $ apt list tzdata tzdata 2018e-1 x86_64 [installed, automatic] and has not changed since the TCI announcement in 2017, updated in 2017c, generated on Oct 20, released on Oct 23 (boy, was last year controlled?): $ head -20 tz/releases/tzdata2017c/NEWS News for the tz database Release 2017c - 2017-10-20 14:49:34 -0700 Briefly: Northern Cyprus switches from +03 to +02/+03 on 2017-10-29. Fiji ends DST 2018-01-14, not 2018-01-21. Namibia switches from +01/+02 to +02 on 2018-04-01. Sudan switches from +03 to +02 on 2017-11-01. Tonga likely switches from +13/+14 to +13 on 2017-11-05. Turks & Caicos switches from -04 to -05/-04 on 2018-11-04. ... when northamerica was changed: # From the Turks & Caicos Cabinet (2017-07-20), heads-up from Steffen Thorsen: # ... agreed to the reintroduction in TCI of Daylight Saving Time (DST) # during the summer months and Standard Time, also known as Local # Time, during the winter months with effect from April 2018 ... # https://www.gov.uk/government/news/turks-and-caicos-post-cabinet-meeting-sta... # # From Paul Eggert (2017-08-26): # The date of effect of the spring 2018 change appears to be March 11, # which makes more sense. See: Hamilton D. Time change back # by March 2018 for TCI. Magnetic Media. 2017-08-25. # http://magneticmediatv.com/2017/08/time-change-back-by-march-2018-for-tci/ # # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Grand_Turk -4:44:32 - LMT 1890 -5:07:10 - KMT 1912 Feb # Kingston Mean Time -5:00 - EST 1979 -5:00 US E%sT 2015 Nov Sun>=1 2:00 -4:00 - AST 2018 Mar 11 3:00 -5:00 US E%sT which shows EST between 1912-1979, EST/EDT until 2015, rezone and stay on AST until 2018, then back to EDT/EST on US rules. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
participants (7)
-
Bradley White
-
Brian Inglis
-
Brian Inglis
-
Jon Skeet
-
Paul Eggert
-
Robert Elz
-
Robert MacGrogan