[LEAPSECS] Windows Server 2019

[Stephen Colebourne]

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.

Stephen