Re: [time-nuts] Leap seconds and POSIX
Joe Gwinn skrev: Having worked in the POSIX committee for many years, I can shed some light on how POSIX handles leap seconds: In short, POSIX adamantly ignores leap seconds. All days in POSIX have the same length, 86,400 seconds. This omission is not by accident, instead having been violently debated at length, and voted upon. The rationale is that one cannot assume that all POSIX systems have access to leap second information, or even the correct time, and yet must work in a reasonable manner. In particular, file modification timestamps must allow one to determine causal order (to within one second in the old days) by comparison of timestamps. (Yes, people do realize that timestamps are not the perfect way to establish causal order, but are nonetheless widely used in non-critical applications. Critical applications instead use some kind of atomic sequence-number scheme.) So, at least in theory, POSIX time is a form of TAI, having a constant offset from TAI. In practice, in platforms that have access to GPS, NTP is used to servo the local computer clock into alignment with UTC (or GPS System Time (UTC without the accumulated leaps) in systems that abhor time steps), and there is a transient error just after a leap second while NTP recovers. The problem with the POSIX time is that it can't be UTC but fails to identify itself as either TAI, UT1 or even UT2. If it clearly identified itself as being one of those, or similar (say GPS time) then things would be much improved. However, it is being interprented as being UTC which it fails to handle. I think the UT1 and UT2 alternatives would be best suited. I don't mind that the default time in POSIX remains there, but I don't think it helps that there is no way to get propper UTC time by a standardized interface. Attempting to say It's UTC, except on leap seconds is not a workable solution if you are locked up and a leap-second do occur. It only works if you are not locked up and free runs on whatever you have. However, more and more systems actually needs to be locked up and they may also need to have propper UTC. We see needs to have logs in UTC and coordinated over many countries and time-zones. This is not only a matter of how we deal with leap-seconds, but how we deal with time. We need to be able to actually deal with propper UTC regardless, and we need to know it is UTC traceable (in a wider sense most of the time, but occasionally in propper sense) or not. I find the current situation unsatisfactory. 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.
Re: [time-nuts] Leap seconds and POSIX
: In practice, in platforms that have access to GPS, NTP is used to : servo the local computer clock into alignment with UTC (or GPS System : Time (UTC without the accumulated leaps) in systems that abhor time : steps), and there is a transient error just after a leap second while : NTP recovers. When the INS bit is set in the NTP packets, NTP tells the kernel about it, which replays the last second of the day to keep in step. I'm not sure this is a transient error or not, since ntp_gettime can be used to determine that this is the leap second for applications that care. However, it does introduce a glitch in the data produced by system interfaces that don't have leap second indicators... Platforms vary because NTP is at the mercy of the kernel developers. From the standpoint of the average user, there is a transient error. Not that many average users will notice, so long as nothing crashes or hangs. For many of the places where POSIX is being used these days, this kind of reasoning is not helpful to say the least. For instance, it is being used in many systems where high availability as well as propper logging is concerned. In addition to that, UTC may very well be the time-scale of choice, thought TAI could be used if properly identified as such. If POSIX standard time where TAI and NTP was steering it as TAI in all the boxes, then things would work. We would need to convert into UTC and then into local time-zone as part of presentation. If POSIX standard time where UTC and NTP was steering it as UTC in all the boxes, then things would work. We would need to convert into local time-zone as part of presentation. Oh, time-zone is a presentation issue and not a box issue. 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.
Re: [time-nuts] Leap seconds and POSIX
Steve, At 8:39 AM + 1/2/09, time-nuts-requ...@febo.com wrote: Message: 6 Date: Fri, 2 Jan 2009 14:00:56 +1300 From: Steve Rooke sar10...@gmail.com Subject: Re: [time-nuts] Leap seconds and POSIX To: Discussion of precise time and frequency measurement time-nuts@febo.com 2009/1/2 Joe Gwinn joegw...@comcast.net: Platforms vary because NTP is at the mercy of the kernel developers. From the standpoint of the average user, there is a transient error. Not that many average users will notice, so long as nothing crashes or hangs. In systems where the transient error and possibility of a crash or hang cannot be tolerated, one common dodge is to lie to NTP by configuring the GPS receiver and NTP timeserver to emit GPS System Time, and live with the fact that the local computer clocks are ~14+ seconds off of UTC. Purpose-built user displays are programmed to compute and use the correct time. Examples please. Examples of what? The systems of my direct experience are radars and the like. Such systems always include trackers, and having a time step or a re-lived second can really destabilize things. To avoid all such problems, one common approach is to create a uniform and smooth timescale for use by the radar software. This was done long before GPS was invented, or NTP for that matter. Now days, the same smooth and uniform timescale is often implemented using a GPS receiver set to emit GPS System Time and NTP to distribute this time to the rest of the radar system. Joe ___ 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.
Re: [time-nuts] Leap seconds and POSIX
Magnus, At 8:39 AM + 1/2/09, time-nuts-requ...@febo.com wrote: Message: 9 Date: Fri, 02 Jan 2009 09:35:59 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] Leap seconds and POSIX To: Discussion of precise time and frequency measurement time-nuts@febo.com Message-ID: 495dd1ef.7030...@rubidium.dyndns.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Joe Gwinn skrev: Having worked in the POSIX committee for many years, I can shed some light on how POSIX handles leap seconds: In short, POSIX adamantly ignores leap seconds. All days in POSIX have the same length, 86,400 seconds. This omission is not by accident, instead having been violently debated at length, and voted upon. The rationale is that one cannot assume that all POSIX systems have access to leap second information, or even the correct time, and yet must work in a reasonable manner. In particular, file modification timestamps must allow one to determine causal order (to within one second in the old days) by comparison of timestamps. (Yes, people do realize that timestamps are not the perfect way to establish causal order, but are nonetheless widely used in non-critical applications. Critical applications instead use some kind of atomic sequence-number scheme.) So, at least in theory, POSIX time is a form of TAI, having a constant offset from TAI. In practice, in platforms that have access to GPS, NTP is used to servo the local computer clock into alignment with UTC (or GPS System Time (UTC without the accumulated leaps) in systems that abhor time steps), and there is a transient error just after a leap second while NTP recovers. The problem with the POSIX time is that it can't be UTC but fails to identify itself as either TAI, UT1 or even UT2. If it clearly identified itself as being one of those, or similar (say GPS time) then things would be much improved. However, it is being interprented as being UTC which it fails to handle. I think the UT1 and UT2 alternatives would be best suited. I don't mind that the default time in POSIX remains there, but I don't think it helps that there is no way to get proper UTC time by a standardized interface. Actually, this isn't quite true, as POSIX provides a standard (POSIX) Re: [time-nuts] Leap seconds and POSIX way to define non-standard (to POSIX) clocks. So, if a vendor felt the need, they could define and provide a real TAI clock for instance. That said, I don't know of anybody having done this, but I have not looked either. Attempting to say It's UTC, except on leap seconds is not a workable solution if you are locked up and a leap-second do occur. It only works if you are not locked up and free runs on whatever you have. However, more and more systems actually needs to be locked up and they may also need to have propper UTC. We see needs to have logs in UTC and coordinated over many countries and time-zones. This is not only a matter of how we deal with leap-seconds, but how we deal with time. We need to be able to actually deal with propper UTC regardless, and we need to know it is UTC traceable (in a wider sense most of the time, but occasionally in propper sense) or not. There are something like 20 named timescales at the international level, most being paper clocks to be sure, but each has a purpose and a set of properties, and serves some need. By implication, there is no single One True Clock. A better way to approach this is to see that POSIX time is yet another timescale, with a purpose and a set of properties. I find the current situation unsatisfactory. It is what it is. Computer platform vendors traditionally cared little about time, and about realtime. The rise of interest in audio and video media caused the vendors to become interested in realtime issues and performance, and thus indirectly about time. But only to the degree needed to support handling of such media. Joe ___ 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.
Re: [time-nuts] Leap seconds and POSIX
Hi Magnus, Joe, et al, Please move the leap seconds and POSIX thread over to the LEAPSECS list. /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.
Re: [time-nuts] Leap seconds and POSIX
Magnus, At 12:00 PM + 1/2/09, time-nuts-requ...@febo.com wrote: Message: 1 Date: Fri, 02 Jan 2009 09:45:23 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] Leap seconds and POSIX To: Discussion of precise time and frequency measurement time-nuts@febo.com : In practice, in platforms that have access to GPS, NTP is used to : servo the local computer clock into alignment with UTC (or GPS System : Time (UTC without the accumulated leaps) in systems that abhor time : steps), and there is a transient error just after a leap second while : NTP recovers. When the INS bit is set in the NTP packets, NTP tells the kernel about it, which replays the last second of the day to keep in step. I'm not sure this is a transient error or not, since ntp_gettime can be used to determine that this is the leap second for applications that care. However, it does introduce a glitch in the data produced by system interfaces that don't have leap second indicators... Platforms vary because NTP is at the mercy of the kernel developers. From the standpoint of the average user, there is a transient error. Not that many average users will notice, so long as nothing crashes or hangs. For many of the places where POSIX is being used these days, this kind of reasoning is not helpful to say the least. But is it correct? Remember, most people understand little and care less about time, except insomuch as it affects something they do care about. There has been a flurry of reports of leap-second induced failures on comp.protocols.time.ntp. This is precisely why some systems must avoid UTC. For instance, it is being used in many systems where high availability as well as propper logging is concerned. In addition to that, UTC may very well be the time-scale of choice, thought TAI could be used if properly identified as such. In the financial and legal worlds, UTC is the standard choice, and many GPS receivers are purchased for legally-tracable timestamping. If POSIX standard time were TAI and NTP was steering it as TAI in all the boxes, then things would work. We would need to convert into UTC and then into local time-zone as part of presentation. I recall Dave Mills discussing this as a possibility, but being unable to achieve it, for reasons I don't recall. If POSIX standard time were UTC and NTP was steering it as UTC in all the boxes, then things would work. We would need to convert into local time-zone as part of presentation. Oh, time-zone is a presentation issue and not a box issue. There is also a move afoot to cease to have leap seconds , instead correcting UTC manually every ten or more years. If this were done, then UTC would become uniform and smooth, and the TAI possibility would be eclipsed. The first possible ITU vote on this would be at their 2010 meeting, the ITU isn't likely to approve something that large the first time, and the DoD proposes that the change not be effective before 2018 at the earliest. Ref: Discontinuance of Leap Second Adjustments, John G. Grimes, Assistant [US] Secretary of Defense, Networks and Information Integration, 3 September 2008, 3 pages. Joe ___ 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] Early leap from SiRF chipset, BU-353
The first column is MJD. The second column is seconds within that day. (I chopped off the right end to avoid line wrap.) 54831 86384.488 $GPRMC,235944.000,A,3726.0731,N,12212.2624,W,0.30, 54831 86385.489 $GPRMC,235945.000,A,3726.0738,N,12212.2624,W,0.45, 54831 86386.489 $GPRMC,235946.000,A,3726.0743,N,12212.2624,W,0.19, 54831 86387.493 $GPRMC,235946.000,A,3726.0749,N,12212.2625,W,0.13, 54831 86388.489 $GPRMC,235947.000,A,3726.0752,N,12212.2625,W,0.46, 54831 86389.489 $GPRMC,235948.000,A,3726.0758,N,12212.2624,W,1.10, It took me a while to figure out what was going on. I got confused when didn't see anything interesting at midnight. 23:59:46 is 14 seconds early. I guess they inserted the leap second at midnight GPS time rather than midnight UTC. -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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.
Re: [time-nuts] Leap seconds and POSIX
In message p06240824c583f02b1...@[192.168.1.212], Joe Gwinn writes: This was done long before GPS was invented, or NTP for that matter. You should check the age of NTP, it is one of the oldest protocols around being initially standardized in september 1985, but inhereting most of its features from ICS which were first standardized in RFC778 in April 1981. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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] GPS12 leap second error
I was sent a NMEA log of a Garmin GPS12 (f/w 4.60) showing the strangest leap second trace yet. Has anyone else see this before? In the ~15 seconds below, note: - double 235957 - missing 235958 for the RMC sentence - no second 235960 for either sentence - strange 59 for the BWC sentence - missing 08 BWC sentence - gps lock lost from 235957 to 43 $GPBWC,235955,,, $GPRMC,235955,A, $GPBWC,235956,,, $GPRMC,235956,A, $GPBWC,235957,,, $GPRMC,235957,A, $GPBWC,235957,,, $GPRMC,235957,V, $GPBWC,235958,,, $GPRMC,235959,V, $GPBWC,59,,, $GPRMC,00,V, $GPBWC,00,,, $GPRMC,01,V, $GPBWC,01,,, $GPRMC,02,V, $GPBWC,02,,, $GPRMC,03,V, $GPBWC,03,,, $GPRMC,04,V, $GPBWC,04,,, $GPRMC,05,V, $GPBWC,05,,, $GPRMC,06,V, $GPBWC,06,,, $GPRMC,07,V, $GPBWC,07,,, $GPRMC,08,V, $GPBWC,09,,, $GPRMC,09,V, $GPBWC,10,,, $GPRMC,10,V, What a mess. /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.
Re: [time-nuts] Leap seconds and POSIX
Poul-Henning Kamp skrev: In message p06240824c583f02b1...@[192.168.1.212], Joe Gwinn writes: This was done long before GPS was invented, or NTP for that matter. You should check the age of NTP, it is one of the oldest protocols around being initially standardized in september 1985, but inhereting most of its features from ICS which were first standardized in RFC778 in April 1981. The first GPS Block I bird flew in 1978, but the project had been ongoing for considerable time. The GPS time coincided with UTC at 6 Jan 1980. Regardless, it is meaningless to even attempt to play the I was here first game. Now, let's take this elsewhere, OK? 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.
Re: [time-nuts] GPS12 leap second error
On Fri, Jan 02, 2009 at 12:13:32PM -0800, Tom Van Baak wrote: I was sent a NMEA log of a Garmin GPS12 (f/w 4.60) showing the strangest leap second trace yet. Has anyone else see this before? In the ~15 seconds below, note: - double 235957 - missing 235958 for the RMC sentence - no second 235960 for either sentence - strange 59 for the BWC sentence - missing 08 BWC sentence - gps lock lost from 235957 to 43 Tom, Keep in mind the GPS12 (and I still have mine) is about 12-13 years old, and was a handheld navigational receiver. No mapping support, no timing support, no WAAS, no DGPS, proprietary Garmin serial + power connector on the back. It's a very basic receiver. It was never, ever intended to be used for timing, and attempting to use it for such results in amusement. I agree the behavior is very odd indeed, so yes, it's an oversight on their part, but I'm not surprised. I didn't even bother to observe mine. --msa ___ 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.
Re: [time-nuts] Leap Quirks
Hal Murray wrote: Two of my Linux systems hung. One was running a 2.6.25 kernel and one 2.6.26. A system running 2.6.23 worked fine. I saw a couple of notes on comp.protocols.time.ntp about Linux systems locking up. One said that it was a kernel bug in ntp.c but I haven't seen any details. None of mine (many dozens) hung.This is typical: c...@snaggle:~$ uname -a Linux snaggle.murgatroid.com 2.6.26-1-amd64 #1 SMP Mon Dec 15 19:40:58 UTC 2008 x86_64 GNU/Linux c...@snaggle:~$ dmesg | grep leap [844362.415072] Clock: inserting leap second 23:59:60 UTC c...@snaggle:~$ -ch ___ 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.
Re: [time-nuts] Leap Quirks
2009/1/3 christopher hoover c...@murgatroid.com: Hal Murray wrote: Two of my Linux systems hung. One was running a 2.6.25 kernel and one 2.6.26. A system running 2.6.23 worked fine. I saw a couple of notes on comp.protocols.time.ntp about Linux systems locking up. One said that it was a kernel bug in ntp.c but I haven't seen any details. None of mine (many dozens) hung.This is typical: c...@snaggle:~$ uname -a Linux snaggle.murgatroid.com 2.6.26-1-amd64 #1 SMP Mon Dec 15 19:40:58 UTC 2008 x86_64 GNU/Linux c...@snaggle:~$ dmesg | grep leap [844362.415072] Clock: inserting leap second 23:59:60 UTC c...@snaggle:~$ Same here with OpenSUSE 11.1 running 2.6.27.7-9-default willow:/home/steve # uname -a Linux willow 2.6.27.7-9-default #1 SMP 2008-12-04 18:10:04 +0100 x86_64 x86_64 x86_64 GNU/Linux willow:/home/steve # grep leap /var/log/messages Jan 1 12:59:59 willow kernel: Clock: inserting leap second 23:59:60 UTC 73, Steve --- Steve Rooke - ZL3TUV G8KVD JAKDTTNW Omnium finis imminet ___ 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.
