While I was looking through dlls/ntdll/time.c I came across the following two comments: "FIXME: Compute the number of leap second corrections here" and "FIXME: get the GMT offset here" What do these this mean? nog.
On Tue, Oct 29, 2002 at 06:45:42PM -0000, György 'Nog' Jeney wrote:
While I was looking through dlls/ntdll/time.c I came across the following two comments: "FIXME: Compute the number of leap second corrections here" and "FIXME: get the GMT offset here" What do these this mean?
Just as there are leap years which have an extra day, from time to time it's necessary to adjust the clock by adding leap seconds because IIRC, a siderial day is not *exactly* 24 hours -- there's a little bit of drift which adds up over time and needs to be corrected for. Steve Langasek postmodern programmer
Hmmm, probably drifting OT here, but ...
On Tue, Oct 29, 2002 at 06:45:42PM -0000, Gy�rgy 'Nog' Jeney wrote:
While I was looking through dlls/ntdll/time.c I came across the following two comments: "FIXME: Compute the number of leap second corrections here" and "FIXME: get the GMT offset here" What do these this mean?
I took this to be a coding question, rather than an astronomical one, so kept quite, but ... On Tue, 29 Oct 2002, Steve Langasek wrote:
Just as there are leap years which have an extra day, from time to time it's necessary to adjust the clock by adding leap seconds because IIRC, a siderial day is not *exactly* 24 hours -- there's a little bit of drift which adds up over time and needs to be corrected for.
which is both right and wrong, so I thought I'd (hopefully ;) clear up any confusion. You're right, sidereal day != solar day. But, that's not what leap seconds are for. A solar day is the time it takes from sun-transit (== "high noon") to sun-transit and is exactly 24 solar-hours. A solar-hour is what most people think of as an hour. A sidereal day is the time between Betelgeuse-transit and Betelgeuse-transit (choosing a star at random ;) It isn't 24 solar-hours, but rather a smidgen over 23 hours, 56 minutes and 4 seconds (I calculated it as 4.1, but the web page I just check said 4.09 ...). The two aren't the same because over the course of a year, the Earth "gains" an extra day. Nothing magical, just that even if the Earth didn't spin (on its axis) you'd still have a day/night period as the Earth goes around the sun. Try it with a grapefruit and a satsuma to see what I mean. Keep the label saying "satsuma" pointing in the same direction and rotate it around the grapefruit. Over "one year", all around the satsuma has faced the grapefruit, indicating a "day" has passed. Ok, so what about leap seconds? It turns out the Earth is slowing down. Not by much, but atomic clocks are sufficiently accurate to measure this. GMT measure time by the Sun (e.g. solar dials), whereas UTC is time measured by atomic clocks. Mostly the difference is just names, but when as Earth starts to slow down, a discrepancy develops and the atomic clocks start to tell the "wrong" time. So, to compensate for this, there are leap seconds. This just "jumps" UTC back whenever the difference between GMT and UTC is around a second. They're introduced in a somewhat ad hoc fashion because the exact rate the Earth is slowing down isn't 100% predictable. HTH ... (Now returning you to your normal program :) ---- Paul Millar
On Tue, Oct 29, 2002 at 01:22:42PM -0600, Steve Langasek wrote:
On Tue, Oct 29, 2002 at 06:45:42PM -0000, György 'Nog' Jeney wrote:
While I was looking through dlls/ntdll/time.c I came across the following two comments: "FIXME: Compute the number of leap second corrections here" and "FIXME: get the GMT offset here" What do these this mean?
Just as there are leap years which have an extra day, from time to time it's necessary to adjust the clock by adding leap seconds because IIRC, a siderial day is not *exactly* 24 hours -- there's a little bit of drift which adds up over time and needs to be corrected for.
I'm fairly sure that the POSIX standard for time ignores leap seconds. So every calender day has 24 * 60 * 60 seconds (except when the clock change for summertime). What isn't clear (form the associated standards) is what you should do to the system clock at the point the leap second is added/subtracted. (Due to variations in the moment of intertia of the earth there have been seconds added aas well as subtracted, even though the earth's rotation is slowing down because the moon keeps stealing angular momentum from it.) David -- David Laight: david(a)l8s.co.uk
On Tue, Oct 29, 2002 at 11:44:18PM +0000, David Laight wrote:
What isn't clear (form the associated standards) is what you should do to the system clock at the point the leap second is added/subtracted. (Due to variations in the moment of intertia of the earth there have been seconds added aas well as subtracted, even though the earth's rotation is slowing down because the moon keeps stealing angular momentum from it.)
Well, if your system clock keeps proper time as measured in seconds since the epoch in UTC :), you don't need to do anything to the system clock; the leap seconds should then be applied when displaying time in the local time zone. Steve Langasek postmodern programmer
On Tue, Oct 29, 2002 at 05:50:10PM -0600, Steve Langasek wrote:
On Tue, Oct 29, 2002 at 11:44:18PM +0000, David Laight wrote:
What isn't clear (form the associated standards) is what you should do to the system clock at the point the leap second is added/subtracted. (Due to variations in the moment of intertia of the earth there have been seconds added aas well as subtracted, even though the earth's rotation is slowing down because the moon keeps stealing angular momentum from it.)
Well, if your system clock keeps proper time as measured in seconds since the epoch in UTC :), you don't need to do anything to the system clock; the leap seconds should then be applied when displaying time in the local time zone.
No - leap seconds have to be ignored when counting time the epoch. Check the posix spec (www.opengroup.org for starters). David -- David Laight: david(a)l8s.co.uk
On Wed, Oct 30, 2002 at 12:01:11AM +0000, David Laight wrote:
On Tue, Oct 29, 2002 at 05:50:10PM -0600, Steve Langasek wrote:
On Tue, Oct 29, 2002 at 11:44:18PM +0000, David Laight wrote:
What isn't clear (form the associated standards) is what you should do to the system clock at the point the leap second is added/subtracted. (Due to variations in the moment of intertia of the earth there have been seconds added aas well as subtracted, even though the earth's rotation is slowing down because the moon keeps stealing angular momentum from it.)
Well, if your system clock keeps proper time as measured in seconds since the epoch in UTC :), you don't need to do anything to the system clock; the leap seconds should then be applied when displaying time in the local time zone.
No - leap seconds have to be ignored when counting time the epoch. Check the posix spec (www.opengroup.org for starters).
POSIX doesn't control the definition of "UTC". If the system clock is stored in UTC, then handling of leap seconds is a requirement when converting from UTC to a local timezone. Steve Langasek postmodern programmer
participants (4)
-
David Laight -
György 'Nog' Jeney -
Paul Millar -
Steve Langasek