On 19 July 2018 at 11:24, Martin Burnicki <[email protected]> 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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
