[ntp:questions] Leap second to be introduced in June

Terje Mathisen terje.mathisen at tmsw.no
Thu Jan 15 07:56:41 UTC 2015

David Woolley wrote:
> On 14/01/15 16:37, Terje Mathisen wrote:
>> The calls I'm thinking of are those you make to convert an OS-supplied
>> time_t (file) system timestamp to YMDHMS etc.
> Those calls have no need to be in the kernel, and they are not in
> Unix/Linux systems.

The standard GetSystemTime* windows calls are also located in usermode 
libraries afaik.

The key issue is that those are documented OS interfaces, not if they 
entail a user/kernel transition or not.

>> I.e. even Windows (which uses a seconds-based timestamp with 100 ns
>> resolution) has calls exactly like that. Those are the calls that would
>> need to be updated in order to work in (TAI * 1e7).
> There is no need to update them on Debian Wheezy, and probably most
> Linux and modern Unix systems.
> david at dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2012
> 86399 seconds'
> Sat Jun 30 23:59:59 UTC 2012
> david at dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2012
> 86400 seconds'
> Sat Jun 30 23:59:60 UTC 2012
> david at dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2012
> 86401 seconds'
> Sun Jul  1 00:00:00 UTC 2012
> I haven't double checked that this is not a trick in the user interface
> code, and they don't work for future time, until the leap second has
> been declared and distributed (in the tzdata files):
> david at dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2014
> 86400 seconds'
> Tue Jul  1 00:00:00 UTC 2014

Did we have a leap second last June? Or did you intend to check for 2015?
> The inability to record future civil times in an efficient format is one
> of the disadvantages of TAI.

Exactly right, which is why I stated that they need to be in a different 
format, like YMDHMS (+zone).

Using Julian day number + fractional day measured in seconds+ns would 
make the required code complexity more or less identical to what we use 
today for seconds + ns.

Re storage needs: time_t has been updated to 64-bit on more or less all 
*ix variants by now, adding in a ns field (which could go all the way to 
1999999999 during a leap second) needs 32 more bits for a total of 96.

If we instead split at the day number then we could use 48-bit JDN plus 
a 48-bit fraction, the end result would be more or less the same range 
and resolution as the current 64:32 split.

The key idea is that we should do all calendar-type calculations based 
on JDN instead of a make-believe UTC 86400 seconds/day.


- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

More information about the questions mailing list