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