From: Markus Kuhn <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED], 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