[LEAPSECS] Toasting Unix timestamp 1234567890
Magnus Danielson
magnus at rubidium.dyndns.org
Sat Feb 14 14:57:09 EST 2009
Zefram skrev:
> Magnus Danielson wrote:
>> Indeed. This is useful for those believing in SI/TAI seconds for as the
>> second distance of time_t, their reference epoch is inconveniently
>> offset in this fashion, making them have an offset of 25,999918 s from
>> POSIX (right now - propper reference scale should be TAI).
>
> Yes.
>
>> Those believing in rubber seconds up to 1972 and then SI/TAI seconds
>> from that will get the more convenient 10 s offset from 1 Jan 1972,
>> making them having an offset of 24 s from POSIX.
>
> No, if you're doing this then you must include the irregular leap.
Sorry, I think you over-interpret a poorly articulated formulation of
mine. If you think according to "Honour the UTC definition from 1970 to
1972 and then the new leap-second based UTC definition from 1972 up to
current time" then I think you should come to the same conclusion as I
do. The honouring of the UTC definitions includes the leaps in offset
both during the pre-1972 definition as well as at the time of change to
the new standard.
> The current offset is about 24.107757997 s, and does not have a terminating
> decimal representation. (This is the counting-UTC-seconds way.)
I do not understand what that number comes from. Does not match what I
meant at least, so you need to describe what it means.
> I believe some people do do the 24 s offset that you suggest, however.
> I think it's through ignorance of the rubber-seconds era and its leaps.
So true.
> These people are effectively using an epoch of 1972-01-01T00:00:00 UTC
> = 63072000. There's no clean description of what they're counting since
> 1970. If doing this then it seems more consistent for pre-1972 timestamps
> to count back in TAI seconds, but in practice I think a vague-UT pre-1972
> timescale gets grafted onto the TAI-synched post-1972 timescale. Bit of
> a mess.
It is a bit of a mess. Honouring the pre-1972 UTC definition for the
pre-1972 era makes sense as it allows for a practical solution at least,
as only integer offsets is involved. The POSIX re-defintion patches the
apparent drift between time_t and UTC datums caused by leap seconds, but
that is a post-1972 era issue and does not fully explains the pre-1972
era behaviour, but could be interpreted to honour the pre-1972 UTC
definition, but then the reference epoch is not occuring at the same
time as the original UNIX GMT defined epoch.
>> 1234567890 seconds of time_t makes no sense at the time that time_t
>> reads 1234567890 since it is not the number of seconds from the
>> reference epoch, it is a form of "mock seconds" to make the scales fit.
>
> Yes. This is sometimes succinctly described as counting "non-leap
> seconds since the epoch".
Well... that only explains the behaviour in the post-1972 era, where as
it does not really help for the pre-1972 era where leap seconds was not
used, so even that wording does not sufficiently covers what is
happening unfortunately.
At 1 Jan 1972 we jumped from 9,892242 to 10 s offset in one fractional
step. Before that we had a 3E-8 s/s phase ramp from 8,000082 of 1 Jan
1970. Neither qualify as leap seconds.
Cheers,
Magnus
More information about the LEAPSECS
mailing list