From: Markus Kuhn <Markus.Kuhn_at_cl.cam.ac.uk>
Subject: Re: [LEAPSECS] The real problem with leap seconds
Date: Mon, 09 Jan 2006 19:12:05 +0000
> "M. Warner Losh" wrote on 2006-01-09 16:57 UTC:
> > There's been many many many people that have tried to fix POSIX time_t.
>
> One person's "fix" is another person's "recipe for disaster" ...
True. All the fixes are worse than the disease. However, let us not
forget that the disease is still bad.
> The POSIX definition of time_t is not quite as broken as some
> individuals would like you to believe. It actually does its job very
> well, especially out there in the real world, where UTC is easily and
> reliably available from many, many, independent channels.
True.
> The same
> surely could not (and probably still cannot) be said for "TAI" and for
> automatic leap-second table updates. You cannot get TAI from the BBC
> evening news, and you still cannot even get it reliably from your
> average local NTP server.
False. Leap second tables are readily available. Current offset
between UTC and TAI is generally available (or computable) from many
time broadcasts (although not all).
> (I know, we've already discussed this here, on tz_at_elsie, on
> pasc-time-study, and on austin-group-l in *very* great detail, many,
> many, many times, so I'll stop.)
POSIX's time_t is broken. Very broken. It is broken accross leap
seconds, and other times. It is convenient because one can get a
decent notion of UTC from many places. However, it is equally easy to
get a notion of TAI time as well, with very minimal effort. One can
easily look on IERS' web page, or download the current leap second
table from
ftp://time.nist.gov/pub/leap-seconds.list with very minmal
effort.
When you have a leap second table, you can run in TAI and compute
intervals correctly. When you don't have a leap second table, you can
run in UTC, but cannot compute intervals correctly (accross leap
seconds). Which set of problem do you want to have? The answer will
very much depend on how connected you are and what the negative
consequences are of computing time intervals wrong are. My
applications tend to be unconnected with big consequences if intervals
are computed wrong, which is the worst of both worlds.
Anyway, time_t is like goto. Sure, you can use it. Sure it usually
won't get you into trouble, but it is being badly abused and that
abuse causes real problems for people that care about accuracy.
Warner
Received on Mon Jan 09 2006 - 11:35:51 PST