Re: [time-nuts] Leap Quirks
One of us is confused about what time_t is... I think it is
you.
time_t is a 32 bit (depreciated), or 64 bit integer that contains
the number of seconds since the epoch. It is not to be adjusted
for leap seconds according to POSIX, and unix convention.
Everything to do with UTC and leap seconds is a library function
in most unixes that translates the leap second free time_t into
the leap second adjusted UTC.
Again, are you telling me that time_t is getting adjusted for leap
seconds? If so, when did this change?
-Chuck Harris
Magnus Danielson wrote:
Chuck Harris skrev:
Poul-Henning Kamp wrote:
In message 495FD637.5030105@erols.com, Chuck Harris writes:
Ok, that is news to me. Are you saying that (pulling a number out of
the air) time_t = 21120123 could be followed by 21120123 on a year where
we added a leap second?
Apart from the number, that is exactly what happens: The last
second of the (UTC) day is recycled twice.
As far as I remember, and as far as I can tell, what you are saying
violates both the unix and POSIX definition of time_t.
So to check, I pulled out both of my K&R editions of "The C programming Language"
and I did a quick google on time_t, and all of the sources I have found
concur that time_t is the number of seconds since 1/1/1970 UTC without
regard to leap seconds.
When did this change?
Depends on which interpretation of POSIX you are making... how you "fit"
your UTC time onto the POSIX scale.
This page can serve as some aid in that puzzle:
http://www.cis.udel.edu/~mills/leap.html
If you want POSIX midnight to fit UTC midnight, then a piece-wise
mapping must be maintained.
Another way would be to just keep POSIX time as SI seconds (or UTC
rubber until 1972 and SI from there on, which is more practical if you
care about details) and solve the UTC issue "outside" the core. Which is
fine too.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Poul-Henning Kamp wrote:
In message 4960027E.1000103@erols.com, Chuck Harris writes:
Poul-Henning Kamp wrote:
Ok, that is news to me. Are you saying that (pulling a number out of
the air) time_t = 21120123 could be followed by 21120123 on a year where
we added a leap second?
Apart from the number, that is exactly what happens: The last
second of the (UTC) day is recycled twice.
[...] and all of the sources I have found
concur that time_t is the number of seconds since 1/1/1970 UTC without
regard to leap seconds.
When did this change?
Never, that's the trouble.
time_t is better defined as:
d * 86400 + min(rs, 86399)
where:
d = Number of complete days since 1970-01-01H00:00:00Z
rs = number of seconds since UTC midnight.
Eliminating leapseconds would make it correct however.
Language is such a problem with these discussions. Your equation
says exactly what I believe to be true, but your use of the word
correct muddles everything for me. POSIXly correct, and unixly
correct is when time_t follows your equation. Following UTC is
another kind of correct: politically correct.
I believe your use of the phrase "make it correct" shows your bias
towards removing the leap second corrections from UTC. This is my
bias as well.
-Chuck Harris
In message 4960CE3D.4080005@erols.com, Chuck Harris writes:
time_t is better defined as:
d * 86400 + min(rs, 86399)
where:
d = Number of complete days since 1970-01-01H00:00:00Z
rs = number of seconds since UTC midnight.
Eliminating leapseconds would make it correct however.
I believe your use of the phrase "make it correct" shows your bias
towards removing the leap second corrections from UTC. This is my
bias as well.
Correct, I don't think leap seconds provide any benefit that
come close to the problems they cause, and I see the cost of
fixing POSIX and auditing all relevant apps after such a change
as totally pointless time & effort spent.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Chuck Harris skrev:
One of us is confused about what time_t is... I think it is
you.
I know of three different ways to interpret it. They fit different purposes.
time_t is a 32 bit (depreciated), or 64 bit integer that contains
the number of seconds since the epoch. It is not to be adjusted
for leap seconds according to POSIX, and unix convention.
This is one, no two, of the interpretations I know of.
Everything to do with UTC and leap seconds is a library function
in most unixes that translates the leap second free time_t into
the leap second adjusted UTC.
Exactly where? Do please tell me what the unified way of getting UTC
time is. Oh, when there is a leap second it needs to give correct
counting as well.
Joe has in private conversations pointed out a POSIX interface which
could be used.
Again, are you telling me that time_t is getting adjusted for leap
seconds? If so, when did this change?
To the best of my knowledge (which can be wrong) this is what is being
done in practice, which is outside of the POSIX standard, but has the
effect that 00:00:00 always midnight, which POSIX needs. This is a third
interpretation...
If somebody (say PHK) got out and slapped my face and say this is a
total misunderstanding, this is pretty good after all. If this practice
does exist, then we still have three interpretations and they are in
conflict with each other even after giving up on introducing leap
seconds. So we have two or three interpretation of the POSIX timescale,
one with pure SI seconds, one with rubber seconds up till
1972-00-00T00:00:00Z and then SI seconds and a third which is like the
second but re-aligned on each leap second event so that midnights match.
This is only an issue if the POSIX scale is under external control.
And yes, do tell me how I get UTC on all platforms.
Regardless, this just shows how complex the issue is. There seems that
there is no "correct" interpretation that everyone can agree with as a
basis. If there is I'll be much happier and go away a bit wiser.
Cheers,
Magnus
Now that the Leap Quirks thread has also morphed into a
discussion about UTC, time_t, and POSIX it should really
be moved over to the LEAPSECS list. The postings are
good, don't get me wrong, and that's all the more reason
they should be posted there instead of time-nuts. Please?
/tvb
I've seen many referencecs to the leapsecs list. would someone please
tell where to find out more about and subscribe to this list?
Thanks,
Eric
On Sun, Jan 4, 2009 at 3:39 PM, Tom Van Baak tvb@leapsecond.com wrote:
Now that the Leap Quirks thread has also morphed into a
discussion about UTC, time_t, and POSIX it should really
be moved over to the LEAPSECS list. The postings are
good, don't get me wrong, and that's all the more reason
they should be posted there instead of time-nuts. Please?
/tvb
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Magnus Danielson wrote:
Chuck Harris skrev:
One of us is confused about what time_t is... I think it is
you.
I know of three different ways to interpret it. They fit different purposes.
time_t is a 32 bit (depreciated), or 64 bit integer that contains
the number of seconds since the epoch. It is not to be adjusted
for leap seconds according to POSIX, and unix convention.
This is one, no two, of the interpretations I know of.
Good!
Everything to do with UTC and leap seconds is a library function
in most unixes that translates the leap second free time_t into
the leap second adjusted broken-down-time UTC.
Exactly where? Do please tell me what the unified way of getting UTC
time is. Oh, when there is a leap second it needs to give correct
counting as well.
If the unix supports leap second, which usually requires ntp, gmtime()
should report the UTC time correctly.
Joe has in private conversations pointed out a POSIX interface which
could be used.
Again, are you telling me that time_t is getting adjusted for leap
seconds? If so, when did this change?
To the best of my knowledge (which can be wrong) this is what is being
done in practice, which is outside of the POSIX standard, but has the
effect that 00:00:00 always midnight, which POSIX needs. This is a third
interpretation...
Yes, but this is not UTC midnight, but unix time or POSIX time midnight.
Unix time midnight, and POSIX time midnight drift from UTC midnight as the
leap seconds get added or removed.
Some of the libc functions that convert time_t to broken down time convert
to UTC, and others convert to POSIX/Unix time... which is, I guess 24 seconds
fast?
Ntpd doesn't mess with time_t when it makes its leap second corrections,
but rather messes with tables and counters used by gmtime(), etal.. The
only time that ntpd messes with time_t is to slew it so that your system's
time_t is the same as everyone elses... (The number of si seconds since
the epoch without adjustments for leap seconds.)
If somebody (say PHK) got out and slapped my face and say this is a
total misunderstanding, this is pretty good after all. If this practice
does exist, then we still have three interpretations and they are in
conflict with each other even after giving up on introducing leap
seconds. So we have two or three interpretation of the POSIX timescale,
one with pure SI seconds, one with rubber seconds up till
1972-00-00T00:00:00Z and then SI seconds and a third which is like the
second but re-aligned on each leap second event so that midnights match.
This is only an issue if the POSIX scale is under external control.
And yes, do tell me how I get UTC on all platforms.
On all platforms? Even my VCR? That's a tall order. On unix
platforms, gmtime() will do the trick... assuming that leap seconds are
supported.
Regardless, this just shows how complex the issue is. There seems that
there is no "correct" interpretation that everyone can agree with as a
basis. If there is I'll be much happier and go away a bit wiser.
The only interpretation that would make me happy is one where UTC no longer
requires leap seconds... but that is a different subject.
-Chuck Harris
Eric Fort wrote:
I've seen many referencecs to the leapsecs list. would someone please
tell where to find out more about and subscribe to this list?
Thanks,
Eric
On Sun, Jan 4, 2009 at 3:39 PM, Tom Van Baak tvb@leapsecond.com wrote:
Now that the Leap Quirks thread has also morphed into a
discussion about UTC, time_t, and POSIX it should really
be moved over to the LEAPSECS list. The postings are
good, don't get me wrong, and that's all the more reason
they should be posted there instead of time-nuts. Please?
/tvb
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.