Version 1.1 of acs/ac-00138.txt

Unformatted version of acs/ac-00138.txt version 1.1
Other versions for file acs/ac-00138.txt

!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.

****************************************************************


Questions? Ask the ACAA Technical Agent