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@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2012
86399 seconds'
Sat Jun 30 23:59:59 UTC 2012
david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2012
86400 seconds'
Sat Jun 30 23:59:60 UTC 2012
david@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@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
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
