!standard 9.6.1(89/2) 06-12-15 AC95-00138/01 !class confirmation 06-12-15 !status received no action 06-12-15 !status received 06-10-30 !subject When should leap seconds be supported? !summary !appendix From: Robert A. Duff Date: Monday, October 30, 2006 4:30 PM RM-9.6.1(89/2) says: Implementation Advice 89/2 {AI95-00351-01} An implementation should support leap seconds if the target system supports them. If leap seconds are not supported, Difference should return zero for Leap_Seconds, Split should return False for Leap_Second, and Time_Of should raise Time_Error if Leap_Second is True. 89.a/2 Implementation Advice: Leap seconds should be supported if the target system supports them. Otherwise, operations in Calendar.Formatting should return results consistent with no leap seconds. In the second sentence of para 89/2, does it mean: - If leap seconds are not supported BY THE TARGET SYSTEM, ... - If leap seconds are not supported BY THE ADA IMPLEMENTATION, ... If the former, it means that if the target system does not support leap seconds, then the Ada implementation should not; i.e. the "if" in the first sentence means "if and only if". If the latter, it means that if the target system does not support leap seconds, then the RM is neutral as to whether the Ada implementation should. I know it's "merely" Implementation Advice, but IMHO implementations should obey Implementation Advice, by and large. The following is perhaps off-topic, but: Does anybody know of target systems that support leap seconds? **************************************************************** From: Robert Dewar Date: Monday, October 30, 2006 5:14 PM > In the second sentence of para 89/2, does it mean: > > - If leap seconds are not supported BY THE TARGET SYSTEM, ... > > - If leap seconds are not supported BY THE ADA IMPLEMENTATION, ... I think the only reasonable interpretation is the first (by the target system), having the Ada run time support leap seconds when the underlying system does not seems a problem. P.S. we already implemented all the leap second junk ourselves, so this intepretation results in extra work taking it out, but I still think it is the right thing to do. **************************************************************** From: Pascal Leroy Date: Monday, October 30, 2006 5:14 PM > In the second sentence of para 89/2, does it mean: > > - If leap seconds are not supported BY THE TARGET SYSTEM, ... > > - If leap seconds are not supported BY THE ADA IMPLEMENTATION, ... Definitely the latter. We do not want to discourage an Ada implementation from supporting leap seconds, even if the target system doesn't. For instance it could get the seconds from a file or a leap-second-aware time source. I believe that the Linux kernel knows about leap seconds, see the man page for adjtimex. Not sure about the older Unix kernels. Windows has not heard about leap seconds yet. But note that even a target system that doesn't have intrinsic knowledge of leap seconds could have its clock adjusted by ntp or by a radio clock. An Ada implementation running on such a system should support leap seconds. **************************************************************** From: Vincent Celier Date: Monday, October 30, 2006 6:05 PM >I believe that the Linux kernel knows about leap seconds, see the man page >for adjtimex. adjtimex is not about support of leap seconds, but about the behaviour of the NTP protocol when a leap second occurs. Support for leap seconds for Linux would be when time(3) and gettimeofday would return a number of seconds since the Unix Epoch that includes the leap seconds. This is not the case on Linux. See time(2) man page: This value is not the same as the actual number of sec- onds between the time and the Epoch, because of leap seconds and because clocks are not required to be synchronised to a standard reference. **************************************************************** From: Tucker Taft Date: Monday, October 30, 2006 5:39 PM MacOSX supports leap seconds. Various routines are involved. time2posix and posix2time convert between a time counter that includes leap seconds in its value and a time counter that doesn't. This came from OpenBSD, I believe. There is also a program called "zic" which seems to build tables used by various time conversion routines, presumably including these two. **************************************************************** From: Vincent Celier Date: Monday, October 30, 2006 6:08 PM This is true only when "the time package is configured with leap-second support enabled" (time2posix man page) otherwise If leap-second support is not enabled, local time_t's and POSIX time_t's are equivalent, and both time2posix() and posix2time() degenerate to the identity function. However, there does not seem to be a documented way to "configure the time package (what is it?) to enable leap second support". **************************************************************** From: Tucker Taft Date: Thursday, November 2, 2006 7:42 AM The following website: http://www.thedjbway.org/clockspeed/leapsecs.html explains that Linux and OpenBSD (upon which MacOSX is based) can be configured to recognize leap seconds as follows: The time zone files on Linux and OpenBSD are located in /usr/share/zoneinfo. Configuring the time zone simply involves making a symbolic link from /etc/localtime to the correct time zone for your locale. The default Linux and OpenBSD configurations are to assume POSIX rules, which ignore leap seconds. For example, the default time zone setup on my system here in Kampala, Uganda is: /etc/localtime -> /usr/share/zoneinfo/Africa/Kampala To configure for leap seconds, just link /etc/localtime to the corresponding time zone file in /usr/share/zoneinfo/right. For example: # ln -s /usr/share/zoneinfo/right/Africa/Kampala /etc/localtime That's it. See also ctime(3). **************************************************************** From: Vincent Celier Date: Thursday, November 2, 2006 10:12 AM > The following website: > > http://www.thedjbway.org/clockspeed/leapsecs.html Thank you, Tucker, for this useful information. > explains that Linux and OpenBSD (upon which MacOSX is based) MacOSX is based on FreeBSD. See http://developer.apple.com/opensource/index.html With its open-source core based on FreeBSD 5.0 and the Mach 3.0 microkernel, Mac OS X is ... As explained in the web page you indicated, the procedure is different for FreeBSD (hence for MacOS). > can be configured to recognize leap seconds as follows: 1) there is another way to do the samething as explained in the procedure you sent: use environment variable TZ Example: bash$ export TZ=right/America/Vancouver 2) when you have setup Linux to use a "right" zoneinfo, the command "date" will display a time 23 seconds in the past, as there have been 23 leap seconds since the Unix Epoch 3) having the clock set up for leap seconds is not sufficient: to fully support leap seconds in Ada.Calendar.Arithmetic, you need to know how many leap seconds have elapsed for every possible value of type Time, otherwise you cannot implement correctly function Difference: procedure Difference (Left, Right : in Time; Days : out Day_Count; Seconds : out Duration; Leap_Seconds : out Leap_Seconds_Count); (of course, it is impossible to guess how many leap seconds will have elapsed for dates far in the future) So, you need to have a table of all the leap second occurences. Do you know of any operating system that provide such a table? **************************************************************** From: Robert Dewar Date: Monday, October 30, 2006 5:46 PM > Definitely the latter. We do not want to discourage an Ada implementation > from supporting leap seconds, even if the target system doesn't. For > instance it could get the seconds from a file or a leap-second-aware time > source. OK, well that's a completely unexpected response. Interesting. What possible justification would an implementation have for NOT supporting leap seconds in this case? Where is the permission to not implement? **************************************************************** From: Robert Dewar Date: Monday, October 30, 2006 5:55 PM By the way, my reasoning in assuming that the IA said not to implement leap seconds if the underlying OS did not is that I could not *IMAGINE* the ARG putting in this junk stuff unless they expected it to be just picked up from the OS. It seems perfectly crazy for me for Ada run times to be keeping private lists of leap seconds! **************************************************************** From: Pascal Leroy Date: Tuesday, October 31, 2006 4:30 PM I have always assumed that every IA is in and of itself a permission to not implement. That is, if the RM says "an implementation should do A", it implicitly says that "an implementation doesn't need to do A". I realize that it's in general a good idea to comply with IAs, but there might be exceptions. If your target system is a GPS satellite, it would be a bad idea to implement leap seconds. Implementers are expected to use their judgment in following IAs. When in doubt, they should give the users some mechanism for configuring the calendar services. **************************************************************** From: Robert Dewar Date: Tuesday, October 31, 2006 12:16 PM > I have always assumed that every IA is in and of itself a permission to > not implement. That is, if the RM says "an implementation should do A", > it implicitly says that "an implementation doesn't need to do A". Sure, but that's only a possible interpretation if the normative part of the standard permits this flexibility. Usually IA is talking about what to do for things that are implementation dependent in any case. Occasionally (as I assumed in this case), IA talks about reasonable appeals to 1.1.3(6). That's why I read the IA in this case the way I did. I assumed that what the IA was saying was that if the system does not support leap seconds, then the advice is to appeal to 1.1.3(6) (AKA AI 325) and declare that support is impractical. If you consider that the IA implies that it is perfectly practical to implement leap seconds in the run time, independent of whether they are implemented in the system, then I see no basis whatever for appealing to 1.1.3(6) and thus I would consider support mandatory. You can't have it both ways! To me the most natural reading of the IA (indeed Gary and I had considered it the only reasonable reading) was that the supported in the second sentence, since it is not qualified in any way, simply refers back to the "supported by the system" phrase in the previous sentence. It seems to me that the real requirement here is that the notion of time embedded in Ada.Calendar precisely match that of the underlying operating system, so that, for example, C programs using C library routines to deal with time, and Ada programs using Ada.Calendar, should have consistent notions of time. If the OS knows nothing about leap seconds, then surely if the Ada run time implements leap seconds this criterion will not be met. Also, I find it VERY uncomfortable for the Ada run time (as is currently the case with GNAT Pro) to include a table of leap seconds that must be constantly updated as new leap seconds are proclaimed. This really seems like it is the province of the operating system, and not the Ada run time, since the latter means that a slightly older version of the compiler has a different notion of time than a newer version of the compiler -- that can't be right. **************************************************************** From: Robert A. Duff Date: Tuesday, October 31, 2006 4:26 PM > I have always assumed that every IA is in and of itself a permission to > not implement. That is, if the RM says "an implementation should do A", > it implicitly says that "an implementation doesn't need to do A". Sure, but that wasn't my question. Let us assume that some implementer wishes to comply with the IA about leap seconds. Obviously, they need to understand what it means. In particular, does it mean, "If the underlying OS does not support leap seconds, then the Ada implementation should not", or does it mean "If the underlying OS does not support leap seconds, then the Ada implementer should use their own judgement"? **************************************************************** From: Robert A. Duff Date: Tuesday, October 31, 2006 4:33 PM > It seems to me that the real requirement here is that the notion of > time embedded in Ada.Calendar precisely match that of the underlying > operating system, so that, for example, C programs using C library > routines to deal with time, and Ada programs using Ada.Calendar, > should have consistent notions of time. That makes a lot of sense to me. My only objection is, what if there is no underlying operating system? Suppose the "target system" (words used in the RM) is so primitive that it just supports a simple hardware counter that increments every nanosecond -- it knows nothing of days, years, Wednesdays, leap seconds, etc. Clearly, the Ada implementation needs to implement the leap-year calculations without relying on the underlying OS (which does not exist). I would think that in such an environment, whether the Ada implementation supports leap seconds should be determined by the Ada implementer's opinion of what their customers want -- i.e. the RM should be neutral w.r.t that environment. **************************************************************** From: Robert Dewar Date: Tuesday, October 31, 2006 4:47 PM That sounds right, though complex calendar stuff is unlikely to be much needed in such an environment! **************************************************************** From: John Barnes Date: Wednesday, November 1, 2006 1:41 AM But it would seem reasonable that if I were doing an off line calculation involving dates and times that I would want leap seconds accounted for if possible. **************************************************************** From: Stephen Michell Date: Wednesday, November 1, 2006 7:38 AM >My only objection is, what if there is no underlying operating system? Suppose >the "target system" (words used in the RM) is so primitive that it just >supports a simple hardware counter that increments every nanosecond -- it knows >nothing of days, years, Wednesdays, leap seconds, etc. Clearly, the Ada >implementation needs to implement the leap-year calculations without relying on >the underlying OS (which does not exist). I would think that in such an >environment, whether the Ada implementation supports leap seconds should be >determined by the Ada implementer's opinion of what their customers want -- >i.e. the RM should be neutral w.r.t that environment. That is a complete red herring. I am developing on such a system. I will need calendar time but I only have a simple counter, so what do I do? I AM NOT going to figure out what the Ada kernel needs to do to provide me reasonable time. Instead I create my own calendar routines that I require and I do as much as I need to get the functionality that I need. Where appropriate I replicate the Ada calling interface and match the Ada semantics but I call it Target.Calendar instead of Ada.Calendar. I will never use the "delay xx.x" function but I do use "delay until xx.x" consistently and I deliver the counter information to the Ada runtime. I am positive that you will find the same answer for almost anyone who is working in an embedded or quasi-embedded environment. I am not sure that I will ever care about leap seconds in this environment. I will eventually be synchronizing with an external time source every few minutes (probably 30 - 100 minutes) and will reset calendar time as required, so I will pick up leap seconds for free. If I am disconnected from my time source for a few days I will likely have more problem with clock drift that problems with a single leap second. **************************************************************** From: Pascal Leroy Date: Monday, November 6, 2006 5:59 AM > adjtimex is not about support of leap seconds, but about the > behaviour > of the NTP protocol when a leap second occurs. ...which is actually very significant. If the kernel decides to adjust the clock frequency when a leap second occurs, there can be interesting jitter/drift effects. > Support for leap seconds for Linux would be when time(3) and > gettimeofday would return a number of seconds since the Unix > Epoch that > includes the leap seconds. This is not the case on Linux. See time(2) > man page: > > This value is not the same as the actual number of sec- > onds between the time and the Epoch, because of leap > seconds and > because > clocks are not required to be synchronised to a > standard reference. We have been discussing what the OS does, but that's largely irrelevant from the perspective of the Ada program/runtime. As Steve M. pointed out, anyone who cares about leap second will have a clock synchronized with an external time source (NTP, a radio clock directly connected to a port, whatever). In such a configuration, the system clock will be adjusted for leap seconds, and the time returned by the C library will actually include the leap seconds, regardless of the fact that Linux itself doesn't know about leap seconds. The situation on MacOS is different in that the OS will use the information in the timezone files to adjust its clock for leap seconds. Nice try, but the drift of the quartz on the motherboard will be several orders of magnitude larger than the leap seconds. So even on MacOS, if you care about leap seconds, you should run NTP, and disable leap second support in the OS. (Apple doesn't put an atomic clock on the motherboard, yet.) > So, you need to have a table of all the leap second > occurences. Do you know of any operating system that provide > such a table? The timezone files that are compiled by zic have a Leap clause that lists the leap seconds. A nice set of timezone files is maintained by the NIH. The compiled files may be analyzed with tzfile.h. ****************************************************************