On Fri, 3 Aug 2018 at 15:27, Robert Elz <kre@munnari.oz.au> wrote:
Date: Fri, 3 Aug 2018 14:56:14 +0100 From: Jon Skeet <skeet@pobox.com> Message-ID: < CA+5fHt+pJv-STH8vkv9mt19U0gih5GsprPaHZiRKOqu2g3+zvw@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