On Fri, 3 Aug 2018 at 14:41, Robert Elz <kre@munnari.oz.au> wrote:
Date: Fri, 3 Aug 2018 13:10:15 +0100 From: Jon Skeet <skeet@pobox.com> Message-ID: <CA+5fHtL1aMO2e_oBoj4QGEHmJvYJ1-uykXDb2r4a=kVkzw+= uw@mail.gmail.com>
| For example, my code to determine transitions got stuck [...] | because multiple UTC instants end up mapping to the same local time
If that is a problem for your validator, then you need to fix it, as that kind of thing can easily happen, whatever the codebase is.
To be clear, this was "subsequent ticks". (A tick is 100ns) 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. 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. Even after this has been worked around there are significant issues though. Jon