[tz] Incorrect Time Zone Data for American/Grand_Turk

[Jon Skeet]

On Fri, 3 Aug 2018 at 15:27, Robert Elz <kre at munnari.oz.au> wrote:

>     Date:        Fri, 3 Aug 2018 14:56:14 +0100
>     From:        Jon Skeet <skeet at pobox.com>
>     Message-ID:  <
> CA+5fHt+pJv-STH8vkv9mt19U0gih5GsprPaHZiRKOqu2g3+zvw at mail.gmail.com>
>
>   | To be clear, this was "subsequent ticks". (A tick is 100ns)
>
> Ah, OK, not what I expected, but ...
>
>   | On further inspection, it looks like the library completely ignores
>   | sub-second precision in some cases: when you ask for the local version
> of
>   | (say) 1998-12-31T23:56:30.123Z in America/Argentina/Buenos_Aires it
> will
>   | return 1998-12-31T20:56:30.000.
>
> I know nothing about Windows data types, or .NET, but you'd see the same
> on most unix implementations, as struct tm has nowhere to put sub-second
> data (nor does time_t) - code that wants to deal with this needs to dig out
> the fractional second, convert the rest, assign the time_t to a struct
> timespec
> (or one of the other variants of that that abound) and then add in the
> fraction.    Doing that is rare...
>

In .NET, I'd *absolutely* expect that to be handled. The details of the C
world are irrelevant to us :) I'd expect any C API that can't respect
sub-second values to make that clear in the API, probably by both accepting
and returning types that only have precision of a second. Whereas DateTime
(the type being used here) has 100ns granularity - and that is preserved in
*most* cases as far as I can see. Goodness knows what's happening behind
the scenes, to be honest.

Basically, my code was detecting this as a change in UTC offset by
one-tick-per-tick (if you see what I mean). So while it would eventually
have produced a tzvalidate file, the file would have been enormous and
contain all these bogus transitions.

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180803/44a13da2/attachment-0001.html>