TAI zone?

walter harms wharms at bfs.de
Thu Jun 30 09:02:32 UTC 2011

Am 30.06.2011 04:46, schrieb Guy Harris:
> On Jun 29, 2011, at 6:53 PM, Robert Elz wrote:
>> is/was supposed to just mean that you have a hardware clock that's
>> ticking TAI (and so doesn't get adjusted for leap seconds), and then
>> the "right" data makes the leap second adjustment so when the data
>> is converted to human form we get the expected (UTC) result that matches
>> the clock on the wall,

In Germany (at least) a lot of private clock use the dcf77 signal what is the official time signal
for germany. And that honors leapseconds, sommertime etc. It is true that you can not get UTC
clocks this is reasonable since most people expect there clock to have localtime.

> Most of the clocks-on-the-wall probably don't give results that match UTC, as they probably always go, at the end of the day-in-Greenwich, from 58 seconds to 59 seconds to 00 seconds, leap seconds notwithstanding.  My watch also knows nothing of leap seconds; I suspect almost nobody's watch does.
> (My work computer, and my home computer, and my mobile phone are another matter, given that they're all running BSD-based UN*X systems.  At least on one of them, the Olson database is built without leap seconds:
> 	$ file /usr/share/zoneinfo/America/Los_Angeles
> 	/usr/share/zoneinfo/America/Los_Angeles: timezone data, old version, 4 gmt time flags, 4 std time flags, no leap seconds, 185 transition times, 4 abbreviation chars
> and I think that's the case with all of them.  My work and home computers sync up against NTP servers, and NTP actually cares about leap seconds, so, while the clock on the menu bar won't go from XX:59:59 to XX:59:60 to YY:00:00 over a positive leap second (at the end of the year, that'd probably be 15:59:59 to 15:59:60 to 16:00:00 out here in California), it'll probably end up in effect getting adjusted for leap seconds.)
> So who was the person who wrote, in the current POSIX rationale:
> 	Most systems' notion of "time" is that of a continuously increasing value, so this value should increase even during leap seconds. However, not only do most systems not keep track of leap seconds, but most systems are probably not synchronized to any standard time reference. Therefore, it is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.
> A clock that's implemented as a hardware counter and a periodic interrupt will, *BY DEFAULT*, "increase even during leap seconds", without having to "keep track of leap seconds".  Was the person who wrote that unaware of that, or are they concerned about, say, machines with hardware clocks that have year/month/day/hour/minute/second or something "helpful" such as that?
> "Most systems are probably not synchronized to any standard time reference" would be a more serious reason than "most systems [do] not keep track of leap seconds" not to "require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch", as per your note that "The occasional leap second correction is typically more minor than the correction needed due to hardware imperfections."
> In practice, I suspect that time_t doesn't explicitly stop across positive leap seconds or jump ahead across negative leap seconds, but, on most systems, might be adjusted by NTP etc. so that, in the sufficiently long run (which is probably at most only a few minutes) it has the same effect.  A system really using an atomic clock might well really truly tick time_t once per second without any other changes, so that, if the Olson database lacks leap second information, "date -u" command won't print out the correct UTC label for the time, given that a POSIX-conformant system must "interpret "536457599 seconds since the Epoch" as 59 seconds, 59 minutes, 23 hours 31 December 1986".

i agree on that the posix people have the wrong impression (maybe coming for a
country that does not have a propper (free) time signal). E.g. most dsl routers
use ntp to sync themself with the net and mots people simple use that routers
to get a propper time (most without realizing it, (author ?)).

It is reasonable to assume that time is monotonic but what resolution ? for day by day living 1s is ok.
Changing the length of a second is a technical fix that means a change below the resolution that is needed.
I can understand WHY some people would like to have thinks like TAI but that technical requirement simply
does not fix the really in this universe.

just my 2 cents,

ps: we have wallclocks that show utc time but they do not use dcf77 so much to reality :)

@guy harris
thx for digging for that references

More information about the tz mailing list