[LEAPSECS] Windows Server 2019

Stephen Colebourne scolebourne at joda.org
Thu Jul 19 06:39:08 EDT 2018

On 19 July 2018 at 11:24, Martin Burnicki <martin.burnicki at meinberg.de> wrote:
> As far as I know, UTC-SLS is done locally on a client, and since it's
> implemented in a Java runtime it is only "seen" by Java applications.
> This means if you get timestamps in Java and non-Java applications on
> the same machine then they may be off by up to 1000 s at the end of the
> UTC-SLS smear interval, isn't it?
> If you have a smearing NTP server then all clients of the same server
> will have the same smeared time, which is of course off UTC during the
> smear interval, but at least all Java and non-Java applications on a
> particular machine will see the same system time.
> I think it depends on the requirements of the applications which way is
> to be preferred.

True, but the point is that we have already, and are likely to have
more in the future, boundaries that want different representations.
Specifically, cases where a low level system understands and models
leap seconds, but a high level system does not want to (for various
perfectly good reasons). Once it is accepted that there are two
representations, and both are valid, there is a need to convert
between the two.

For the plan to work fully it needs to be possible for any of these
setups to be valid (and maybe more options too):

- network clock returns UTC, OS handles UTC, application/framework handles UTC
- network clock returns UTC, OS handles UTC, application/framework smears
- network clock returns UTC, OS smears, application/framework unaware
- network clock smears, OS unaware, application/framework unaware

Getting the smear off the network and into the OS will undoubtably be
useful in some use cases, but they are not the only use cases.


More information about the LEAPSECS mailing list