[email protected] (Chris Adams) wrote:
Once upon a time, Phil W Lee <[email protected]> said:
For the tiny number of programs which really need UTC (not TAI), it
would just be a different number, but the only thing I know of which
really needs UTC rather than TAI would be programs to assist with
astronomy or astral navigation.
I think one problem with OS clocks in TAI is that counting it correctly
requires active/on-going maintenance at unknownable intervals for all
systems that use any form of timestamps (including for example anything
that uses network file systems).
Also, you can't properly represent future timestamps (necessary for some
things) as seconds since an epoch, and that's pretty widely used. By
that I mean that the number of seconds between 2015-06-30 23:59:00 and
2015-07-01 00:00:00 has changed since last month.
Adn this is _exactly_ why it is always a bad idea to use (UTC) seconds
for those future timestamps:
If you actually mean that something has to happen N seconds from now,
that future timestamp has to be in TAI, since using UTC would obviously
blow up across any leap second, right?
If you instead meant a calendar event, then you need a different
timescale which is either Julian Day Number (JDN) or YMD, followed by
either HMS or an offset into the day, followed by the applicable time zone.
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
