[tz] Incorrect Time Zone Data for American/Grand_Turk

[Robert MacGrogan]

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 at 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 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
>>> <https://maps.google.com/?q=530+Means+Street,+Suite+405+%C2%A0+Atlanta,+GA+30318&entry=gmail&source=g>
>>>
>>> Atlanta, GA 30318
>>> <https://maps.google.com/?q=530+Means+Street,+Suite+405+%C2%A0+Atlanta,+GA+30318&entry=gmail&source=g>
>>>
>>> <https://maps.google.com/?q=530+Means+Street,+Suite+405+%C2%A0+Atlanta,+GA+30318&entry=gmail&source=g>
>>> www.flightbridge.com
>>>
>>>
>>>
>>>


-- 

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/1a894b14/attachment.html>