dmagda at ee.ryerson.ca
Thu Jun 30 11:24:24 UTC 2011
On Jun 30, 2011, at 02:27, Robert Elz wrote:
> And further, the initial request is also pretty meaningless, TAI is not
> (unlike UTC) a timezone, so TZ=TAI makes precisely no sense at all.
> As best I understand it, TAI is just a count of seconds from its offset,
> and has no concept of years, months, or days, just seconds, and so attempting
> to use the localtime() set of functions on TAI data makes precisely no
Unix-y systems keep time in POSIX "time scale" (?), and NTP uses UTC.
Given that TAI is neither of these, if one would like to use a time scale that does not experience leap seconds, one need a way of telling the various time routines to translate the internal POSIX/UTC counters to a different "local" time.
As I type this, my TZ=America/Toronto, and so the time is roughly:
Thu Jun 30 07:20:50 EDT 2011
Thu Jun 30 11:20:50 UTC 2011
but if I set TZ=TAI, it would convert my NTP synced computer clock up by 34s:
Thu Jun 30 11:21:24 TAI 2011
So yes, TAI is "just a count of seconds from its offset", but how does one tell a utility like date(1) to add those seconds? Hence my original question: if all these people who can't / don't want to deal with leap seconds want something that ignores it, what option would they have? Would a TZ=TAI be possible?
(This may be moot if leap seconds are voted away of course.)
More information about the tz