<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, 3 Aug 2018 at 15:27, Robert Elz <<a href="mailto:kre@munnari.oz.au">kre@munnari.oz.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">    Date:        Fri, 3 Aug 2018 14:56:14 +0100<br>
    From:        Jon Skeet <<a href="mailto:skeet@pobox.com" target="_blank">skeet@pobox.com</a>><br>
    Message-ID:  <<a href="mailto:CA%2B5fHt%2BpJv-STH8vkv9mt19U0gih5GsprPaHZiRKOqu2g3%2Bzvw@mail.gmail.com" target="_blank">CA+5fHt+pJv-STH8vkv9mt19U0gih5GsprPaHZiRKOqu2g3+zvw@mail.gmail.com</a>><br>
<br>
  | To be clear, this was "subsequent ticks". (A tick is 100ns)<br>
<br>
Ah, OK, not what I expected, but ...<br>
<br>
  | On further inspection, it looks like the library completely ignores<br>
  | sub-second precision in some cases: when you ask for the local version of<br>
  | (say) 1998-12-31T23:56:30.123Z in America/Argentina/Buenos_Aires it will<br>
  | return 1998-12-31T20:56:30.000.<br>
<br>
I know nothing about Windows data types, or .NET, but you'd see the same<br>
on most unix implementations, as struct tm has nowhere to put sub-second<br>
data (nor does time_t) - code that wants to deal with this needs to dig out<br>
the fractional second, convert the rest, assign the time_t to a struct timespec<br>
(or one of the other variants of that that abound) and then add in the<br>
fraction.    Doing that is rare...<br></blockquote><div><br></div><div>In .NET, I'd <i>absolutely</i> 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 <i>most</i> cases as far as I can see. Goodness knows what's happening behind the scenes, to be honest.</div><div><br></div><div>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.</div><div><br></div><div>Jon</div></div></div>