[tz] Incorrect Time Zone Data for American/Grand_Turk
skeet at pobox.com
Fri Aug 3 10:56:51 UTC 2018
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.)
On Fri, 3 Aug 2018 at 11:52, Robert MacGrogan <rmacgrogan at flightbridge.com>
> Thanks for your help. I'll see if I can take this up with the Ak Zone Info
> 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>
> [image: FlightBridge] <http://www.flightbridge.com/>
> FlightBridge, Inc.
> 530 Means Street, Suite 405
> Atlanta, GA 30318
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz