Re: [Ntp] Antw: [EXT] Timescales, leapseconds and smearing

>>> Kurt Roeckx <kurt@roeckx.be> schrieb am 08.12.2020 um 12:05 in Nachricht
<X89eBhhdUDijLVpL@roeckx.be>:
> On Tue, Dec 08, 2020 at 10:56:24AM +0100, Ulrich Windl wrote:
>> Hi!
>> 
>> I think if we agree to use anything other than UTC in NTPv5, we absolutely
>> need to specify some use-level API how to get the current time:
>> time()
>> gettimeofday()
>> clock_gettime()
>> localtime()
>> strftime()
>> 
>> They all assume UTC... It's rather useless if NTP has the exact time, but
no
>> ("standard") program can use it.
> 
> They don't use UTC, they use POSIX/UNIX time. POSIX time, just like
> NTP, ignores the leap seconds. POSIX actually says that the length
> of a second is not specified, an implementation can then say it's
> SI seconds. POSIX has support for a leap second in struct tm, so as
> long as you don't convert it to a time_t you can work in UTC.
> strftime() works with a struct tm, so can work in UTC.
> 
> The linux kernel has support for TAI. You can set a TAI offset, so
> that applications making use of the POSIX API still get the POSIX
> time. The clock_gettime() function you mentioned has TAI support.
> The information to convert from TAI to UTC is available, so it's
> possible to work in TAI or UTC on Linux, it's just that most
> applications don't.

Hi!

So your poposal is that an NTP implementation passes struct tm directly to the
application? And how will the application get the time when the NTP service is
not running?

You may be right in your arguments, but it really does not solve the problem.

Regards,
Ulrich

> 
> 
> Kurt
> 
>> >>> Kurt Roeckx <kurt@roeckx.be> schrieb am 07.12.2020 um 23:27 in
Nachricht
>> <X86sVykHUqlkXP96@roeckx.be>:
>> > We have various timescales people might care about:
>> > ‑ NTP
>> > ‑ TAI
>> > ‑ Smeared NTP
>> > ‑ UT1
>> > ‑ UTC
>> > ‑ UNIX time
>> > ‑ TT
>> > ‑ GPS
>> > ‑ Others
>> > 
>> > There are relations between those time scales, some are fixed,
>> > others not.
>> > 
>> > The proposed draft has support for the first 4, and offsets
>> > between some of them. Note that it calls the NTP timescale
>> > UTC, which it's not.
>> > 
>> > One problem that NTP currently isn't very good at is dealing with
>> > the leap second. The current draft proposal doesn't address the
>> > problems. The major problems with it are:
>> > ‑ The NTP timescale is non‑continues in case of a leap second,
>> >   without an indication of on which scale you are. It also
>> >   doesn't define which second should get repeated. This means there
>> >   is a 2 second window where it's unclear what the time is.
>> > ‑ There is a need to distribute information about when a leap second
>> >   will happen, which for can happen over NTP or some other way.
>> >   Experience shows that a lot of NTP servers get this wrong,
>> >   resulting in synchronization problems when some servers change
>> >   and others not. When distributed over NTP, a majority of the
>> >   servers need to indicate that it will happen. There is no way
>> >   to indicate that you don't know a leap second will happen or
>> >   not, making it harder to get it correct.
>> > 
>> > You can fix the first problem by moving to a scale that is
>> > continues, like TAI. But I'm not sure if it's better or worse
>> > because of the 2nd problem, it will probably be about the same.
>> > In TAI it would always be clear what the time means, even if some
>> > servers know about the leap seconds and others not. It would avoid
>> > marking some servers as false tickers. The current proposed draft
>> > supports working in TAI and smeared NTP. I'm not sure about the
>> > UT1 scale in the draft but assume it's non‑continues.
>> > 
>> > An other way to fix the non‑continues problem is to have some
>> > indication of on which scale you are. It needs to be able to say
>> > in which scale each of the timestamps is. The proposed draft has a
>> > TAI‑UTC offset if you use the NTP scale that could be used for this,
>> > but it would then apply to both timestamps. If that is what we
>> > want to do, it needs to be more clear. But for the UT1 scale there
>> > is no way to indicate it.
>> > 
>> > NTP could distribute information about difference between
>> > timescales. A leap second will change the offsets, so we already
>> > do this in a very limited way. TAI‑UTC and UT1‑UTC are mentioned in
>> > the proposed draft, but it depends on which timescale you're using
>> > which offset you can get. I'm not sure NTP is the best way to
>> > distribute it. But for a lot of devices NTP is the only source of a
>> > leap second information.
>> > 
>> > The document also has a smeared NTP option. It doesn't actually
>> > say which time you put in the fields, the NTP time, or the smeared
>> > NTP time. It then has an offset to the NTP time, without being
>> > clear about the sign. The offset is also optional, which means you
>> > might not be able to combine servers that smear, that smear
>> > differently and that don't smear.
>> > 
>> > I'm currently not sure if we should do something with smearing. We
>> > could for instance say that even if the server is smearing, NTP
>> > should always contain unsmeared time, and that smearing is an
>> > implementation detail. Or we could standardize how it should be
>> > smeared. Or like the current draft that you have smear offset.
>> > 
>> > 
>> > Kurt
>> > 
>> > 
>> > _______________________________________________
>> > ntp mailing list
>> > ntp@ietf.org 
>> > https://www.ietf.org/mailman/listinfo/ntp 
>> 
>> 
>> 