[tz] Incorrect Time Zone Data for American/Grand_Turk

[Jon Skeet]

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 at 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 at 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 at 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 at flightbridge.com  <rmacgrogan at flightbridge.com>
>> 850-509-6158
>>
>> [image: FlightBridge] <http://www.flightbridge.com/>
>>
>> FlightBridge, Inc.
>> 530 Means Street, Suite 405
>> Atlanta, GA 30318
>> www.flightbridge.com
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180803/0ad52f54/attachment.html>