Fwd: Re: F-ckin Leap Seconds, how do they work?
---------- Forwarded message ---------- From: "shawn wilson" <ag4ve.us@gmail.com> Date: Jul 3, 2012 11:33 AM Subject: Re: F-ckin Leap Seconds, how do they work? To: "Joel jaeggli" <joelja@bogus.com> I agree with TAI. Epoch is supposed to be an unsigned long int starting ~1970 (there are are 4 epochs iirc, but never mind that). I don't recall the rfc, but I don't recall this spec mentioning leap seconds (and it shouldn't). Frankly our time system is buggy as hell (no year 0, base 60 seconds and minutes, base 24 hours, no standard month base, e/m isn't a part of the system, etc). I find my last issue the most disconcerting with our system and makes it really unreliable - GPS time is *not* earth time and we rely on that skew for everything. To that point, I hate to think how many missile tests it took them to figure that one out :) However there is no reason to add more crap to an already messed up system. On Jul 3, 2012 10:03 AM, "Joel jaeggli" <joelja@bogus.com> wrote:
On 7/3/12 01:54 , Wolfgang S. Rupprecht wrote:
Steven Bellovin <smb@cs.columbia.edu> writes:
See
http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.htm...
Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way.
Neither timezones nor dst impact length of the mean solar day.
TAI is some 35 seconds ahead of UTC this point. and will continue to diverge in a fashion which is not sufficiently predictable that you can know over the long term.
Not using utc as the timebase is certainly possible, gps does that for example.
Apps are buggy sounds like a really poor excuse for doing so.
-wolfgang
On Tue, 03 Jul 2012 11:35:00 -0400, shawn wilson said:
and makes it really unreliable - GPS time is *not* earth time and we rely on that skew for everything. To that point, I hate to think how many missile tests it took them to figure that one out :)
Actually, GPS time is pretty ugly mathematically, as it has to make relativistic corrections for time dilation due to speed of the satellites and for gravity-well dilation (which are in opposite directions). You don't want to go there in a world where programmers still get the 400 rule for leap years wrong. ;)
Once upon a time, valdis.kletnieks@vt.edu <valdis.kletnieks@vt.edu> said:
Actually, GPS time is pretty ugly mathematically, as it has to make relativistic corrections for time dilation due to speed of the satellites and for gravity-well dilation (which are in opposite directions).
That's how GPS _calculates_ the time, but "GPS time" (i.e. time as reported by GPS) is a constant offset from TAI (TAI - UTC as of 1980). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
participants (3)
-
Chris Adams -
shawn wilson -
valdis.kletnieks＠vt.edu