[LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Martin Burnicki]

Hal Murray wrote:
> 
> sla at ucolick.org said:
>> This idea pushes extra complexity into every implementation of low level
>> kernel-space software, firmware, and hardware.  That's nice as a policy for
>> full employment of programmers, but it's hard to justify by any other
>> metric.  Instead those low level places should be as simple as possible, and
>> that means making the underlying precision time scale, and thus any
>> broadcast distributions of a precision time scale, as simple as possible. 
> 
> Has anybody done any serious thinking about fixing the POSIX problem?
> 
> I assume the first step would be to have the kernel keep time in a non 
> leaping time scale.  Is UT1 the obvious choice?

Wouldn't that basically mean to get back rubber band seconds? Also, how
would you distribute UT1? Via a table with a correction value to TAI?

IMO a better approach would be to let the system time run on TAI, and do
the conversion to UTC, and local time in the next step, by runtime
libraries. The tzdist protocol could be used to update both the TZ DB
and the leap second table.

This could solve the ambiguity of duplicate time stamps which you also
have at the end of a DST interval, unless you know the DST status. I
mean at least the conversion from TAI to UTC.

The conversion from UTC back to TAI can only be unambiguous if you have
some status information with the time stamp. For example, if you want to
derive UTC from local time then you need to know the basic local time
offset *and* the DST status. Otherwise you get ambiguous conversion
results at least at the end of a DST period where 1 hour is repeated.

This is similar with UTC. If the timestamp APIs always returned a
timestamp+status you could deal with that unambiguously. However,
implementation of the API would be expensive with regard to computation
time since it has to make sure that the time stamp and status
information are always returned consistently. This is bad for
applications which want to read time stamps as fast as possible.

> Would we need a version of ntp that used that time scale?  (or some 
> non-leaping time scale)

I think a compatible approach would be to let existing API calls behave
like they do now, and provide new enhanced API calls where the
application can determine if the kernel runs on TAI, and then use
different calls to return a TAI time stamp only, or a raw UTC time stamp
derived from TAI, or a time stamp plus status to resolve the ambiguity.

For example, Meinberg PCI cards provide API calls which return a 64 bit
time stamp very fast for applications which need it, and there are other
API calls which return a UTC time stamp, plus local time offset, plus a
status field indicating if the device is synchronized, if a leap second
is pending, if the current time stamp is in the middle of a leap second,
etc.

Martin