[tz] Incorrect Time Zone Data for American/Grand_Turk
skeet at pobox.com
Fri Aug 3 14:34:08 UTC 2018
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
> | (say) 1998-12-31T23:56:30.123Z in America/Argentina/Buenos_Aires it
> | 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
> (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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz