<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, 3 Aug 2018 at 14:41, Robert Elz <<a href="mailto:kre@munnari.oz.au">kre@munnari.oz.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">    Date:        Fri, 3 Aug 2018 13:10:15 +0100<br>
    From:        Jon Skeet <<a href="mailto:skeet@pobox.com" target="_blank">skeet@pobox.com</a>><br>
    Message-ID:  <CA+5fHtL1aMO2e_oBoj4QGEHmJvYJ1-uykXDb2r4a=kVkzw+=<a href="mailto:uw@mail.gmail.com" target="_blank">uw@mail.gmail.com</a>><br>
<br>
  | For example, my code to determine transitions got stuck [...]<br>
  | because multiple UTC instants end up mapping to the same local time<br>
<br>
If that is a problem for your validator, then you need to fix it, as that<br>
kind of thing can easily happen, whatever the codebase is.<br></blockquote><div><br></div><div>To be clear, this was "subsequent ticks". (A tick is 100ns)</div><div><br></div><div>Yes, I absolutely cope with clocks going back. There's a big difference between that and "time stops completely for a second" which is what's actually observed with the library.</div><div><br></div><div>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.</div><div><br></div><div>Even after this has been worked around there are significant issues though.</div><div><br></div><div>Jon</div><div><br></div></div></div>