I hadn't come across Afk.ZoneInfo before. I'll take an action to write a tzvalidate implementation for it.

In the meantime, you may want to consider using my Noda Time 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
850-509-6158
FlightBridge, Inc.
530 Means Street, Suite 405
Atlanta, GA 30318
www.flightbridge.com