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.
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.
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.
[time-nuts] Leap seconds and POSIX
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. 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
In message: p06240822c582a02c4...@[192.168.1.212] Joe Gwinn joegw...@comcast.net writes: : 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.) If POSIX had allowed for the system time to be TAI, and have the offset applied for the display of times, then there would be no ambiguity. However, this is not allowed because one must be able to do math on time_t such that time_t % 86400 is midnight. : So, at least in theory, POSIX time is a form of TAI, having a : constant offset from TAI. Except that the offset isn't constant :(. : 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... Warner ___ 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: 20090101.112803.179959520@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : If POSIX had allowed for the system time to be TAI, and have the : offset applied for the display of times, then there would be no : ambiguity. However, this is not allowed because one must be able to : do math on time_t such that time_t % 86400 is midnight. time_t %86400 == 0 is midnight I should have said... Warner ___ 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
Warner, At 6:35 PM + 1/1/09, time-nuts-requ...@febo.com wrote: Message: 6 Date: Thu, 01 Jan 2009 11:28:03 -0700 (MST) From: M. Warner Losh i...@bsdimp.com Subject: Re: [time-nuts] Leap seconds and POSIX To: time-nuts@febo.com, joegw...@comcast.net Message-ID: 20090101.112803.179959520@bsdimp.com Content-Type: Text/Plain; charset=us-ascii In message: p06240822c582a02c4...@[192.168.1.212] Joe Gwinn joegw...@comcast.net writes: : 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.) If POSIX had allowed for the system time to be TAI, and have the offset applied for the display of times, then there would be no ambiguity. However, this is not allowed because one must be able to do math on time_t such that time_t % 86400 is midnight. Defining a formal equivalence of some kind to TAI was proposed, but was not accepted, largely because they had were not linked at the beginning, and there would be many details that were not quite right. : So, at least in theory, POSIX time is a form of TAI, having a : constant offset from TAI. Except that the offset isn't constant :(. True, as discussed next. : 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. 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. 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
In message p06240823c582ce020...@[192.168.1.212], Joe Gwinn writes: Not that many average users will notice, so long as nothing crashes or hangs. If the above statement reflects the POSIX attitude to operating system quality and reliability, then I understand, for the first time, how POSIX can contain so many mistakes, omissions and bad ideas usually terribly executed. Poul-Henning -- 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.
Re: [time-nuts] Leap seconds and POSIX
-Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Poul-Henning Kamp Sent: Thursday, January 01, 2009 2:03 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Leap seconds and POSIX In message p06240823c582ce020...@[192.168.1.212], Joe Gwinn writes: Not that many average users will notice, so long as nothing crashes or hangs. If the above statement reflects the POSIX attitude to operating system quality and reliability, then I understand, for the first time, how POSIX can contain so many mistakes, omissions and bad ideas usually terribly executed. Poul-Henning I take this as being one user's pragmatic opinion, not a statement of policy. Not that I would disagree with you if it were. POSIX is like the government in a democracy: necessary evil. Didier ___ 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
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. 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.
