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