At 3:19 PM +0200 10/11/09, Magnus Danielson wrote:
Joe Gwinn wrote:
Magnus,
At 5:10 PM +0200 10/10/09, Magnus Danielson wrote:
Joe,
Joe Gwinn wrote:
At 3:28 PM +0200 10/10/09, Magnus Danielson wrote:
M. Warner Losh wrote:
In message: <4acff759.3090...@rubidium.dyndns.org>
Magnus Danielson <mag...@rubidium.dyndns.org> writes:
[snip]
Yes. The most current time_t definition is the one codified by POSIX.
Older standards are fuzzier about what time_t really means.
Indeed. As there exist several time_t definitions, I wanted to
make sure you was refering to the POSIX mapping of UTC time into
time_t, which forms an "interesting" timescale of its own,
almost but not close enough to UTC.
By definition, POSIX Time is closer to TAI than to UTC, but in
practice time in POSIX-compliant computers is usually NTP steered
to approximate UTC (most common) or to GPS System Time (where
leapseconds cannot be tolerated).
As the text of subclause 4.14 of the POSIX base standard defines
it, it is based on "Coordinated Universal Time" and the "name" is
mapped into seconds as defined by the mapping function. This makes
it follow UTC while maintaining the mental feel of being TAI-based
without any leap seconds, but it is closer to UTC as only
occasionally (on the leap second second) differs by a second
during a second while it has a so far constantly increasing
difference to TAI. So on average it is much closer to UTC than TAI.
So I respectfully disagree with your statement that POSIX Time is
closer to TAI than UTC. I think that it is closer to UTC and that
the NTP steering honour the POSIX UTC to time_t mapping.
Be careful to distinguish "broken down time" (an ascii string that
resembles UTC) from the underlying clock (two 32-bit integers that
are supposed to count SI seconds and nanoseconds since the POSIX
Epoch).
This is why I write "POSIX time_t" rather than "POSIX time" to start
with, to indicate that I mean the integer number value.
OK, but there are different forms of the same timescale.
If you read the POSIX standard, you will find that the length of
the day is defined as exactly 86,400 seconds, no more no less. So,
leap seconds are by definition forbidden. This was the intent of
the committee.
I fully recognice this fact and see the POSIX time_t to be defined
in such a way, yes.
Another common source of confusion is that the POSIX Epoch is an
instant defined in UTC terms, but one can define an instant in any
timescale one wishes, and the instant may appear in all of them but
belongs to none of them.
You can use any timescale of choice, but the definition actually
brings in UTC explicitly, and that is not a random timescale.
My point is that even though the POSIX timescale Epoch is defined in
UTC, that does not make the POSIX timescale the same as UTC.
Leapseconds are integral to UTC, and yet POSIX Time has no
leapseconds.
Had the selection been TAI (or a suitable shift of it) it would have
solved alot of problems, as relative measures between time_t would
work well and absolute time stamps througout would be consistent and
the issue of leapseconds would be hidden in the presentation into
broken down time as libc performs it. If the text was not using the
wording relating to UTC the issue would be quite different.
I completely agree.
However, most people who care even a little about time use NTP to
synchronize their computer's time to something, and by far the bulk
of the relevant timeservers publish UTC, never mind the formal
definition of POSIX Time. So, in practice time on such systems is
neither fish nor fowl, being neither TAI not UTC, instead being a
mixture.
NTP honour the UTC to time_t mapping. It does not give the correct
23:59:60 reading thought, as the POSIX time_t system does not allow
that.
And with this too.
A user wishing to display correct UTC time during leap-second
would need to querry the NTP kernel over the provided interface
to recover the extra information, which is possible when the NTP
has the necessary leapsecond information and is enabled.
A tall order for sure, and one is completely at the mercy of the
operating system kernel developers, who may be hazy on the details
of time.
In the systems I have had a hand in, the computer clocks are
synchronized to GPS System Time (because those systems cannot
tolerate the discontinuities caused by leap seconds) and UTC is
made by the application software only where needed when needed.
That will work. I have no trouble with using a continous scale at
the core, it just happends to be that I don't intereprent the POSIX
time_t definition to provide that, it provides to me a time which
looks continous, but there is occasional hickups if you follow the
definition.
Well, if people actually followed the POSIX Time definition to the
letter, there would be no hiccups. But nobody follows the definition
that strictly. Except those who disseminate GPS System Time via NTP,
thereby sidestepping the whole leapsecond problem.
To be clear, within the POSIX time_t system, days are exactly 86400
seconds long, and within that context broken down time and compound
time is consistent. The problem lies in how the defined mapping from
UTC to time_t is done, as the UTC broken down time (still) includes
leap seconds. The UTC reading 23:59:60 will be a legal UTC name
which still needs to be converted into POSIX time_t and when it is,
the 00:00:00 second occurs twice. This is what the definition means,
as POSIX can't rule out the legal UTC leap second readings.
Sure POSIX can exclude leapseconds, as POSIX does not claim to be
UTC. If memory serves, POSIX specifically disclaims being UTC.
If you don't care about the fuzziness about not knowing which of
these two seconds something happend or that a time-difference over a
leap second may become 1 second longer than intended, then
configuring an NTP client or hooking a GPS receiver with UTC will
not be much of a deal.
Trouble is when systems needs correct time from ground up and also
needs to follow proper UTC. Then you need to repair it from the
ground up.
Yes. This is exactly why some systems use NTP to distribute GPS System Time.
If the core time was say GPS time based (still maintaining the POSIX
epoch at or near 1970-1-1 00:00:00 GMT/UTC; the GPS epoch is a
decade later) then broken down time would need to make leap second
corrections, but that would work fairly well, as time_t would be
strict 86400 second based but actually count the leap-seconds
properly.
That could work, if NTP and eventually the operating system kernels
were changed to accommodate it. This isn't impossible, but it isn't
likely to be achieved quickly either. But one must start to have any
hope of finishing.
I had the distinct memory that we discussed this in depth some
time ago both on and off list(s).
You've let our secret out! Yes, it was in January 2009.
Right. Not meant to expose you or any ideas in a bad way. Sorry.
No secret and offence taken. I was pulling your leg....
Joe Gwinn
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs