[Scheme-reports] Formal Comment: The epoch of current-second should be 1970-01-01 00:00:00 TAI.

[Alan Watson <alan@x>]

Formal Comment

Submitter's Name:           Alan Watson
Submitter's Email Address:  alan@x
Draft Version of Report:    6

Section of draft R7RS:      6.13 Input and output

Summary: 

The epoch of current-second should be 1970-01-01 00:00:00 TAI.

Full Description:

The current-second procedure in the sixth draft of the R7RS returns the number
of TAI seconds since 1970-01-01 00:00:10 TAI. This epoch corresponds
approximately to the Unix and POSIX epoch of 1970-01-01 00:00:00 UTC. 

The timescale of current-second is sometime referred to as the "TAI-10"
timescale. It is possible to set the system clock of some computers to run on
this timescale rather than the POSIX timescale, although this is uncommon.
Conversion to UTC can then be achieved by using the "right" time zone database.

The precision time community does not formally refer to TAI and UTC in terms of
seconds since an epoch. Instead, they specify a year, month, day, hour, minute,
and second. The precision time community refers to the difference between UTC
and TAI as the number of seconds between the start of a UTC day and the start of
the corresponding TAI day. This offset is determined by the IERS and
disseminated by the IERS and standards bodies such as NIST:

  http://hpiers.obspm.fr/eop-pc/index.php?index=TAI-UTC_tab
  http://data.iers.org/products/16/14889/orig/bulletinc-043.txt
  ftp://time.nist.gov/pub/leap-seconds.list

In early 2012, the offset between TAI and UTC is 34 seconds.

I suspect there are likely to be three common operations on the result of
current-time:

(a) Subtraction to determine intervals in seconds. For this, the epoch is
irrelevant.

(b) Conversion to UTC. In converting to UTC, one has use not the
widely-disseminated difference between TAI and UTC but rather this difference
minus 10 seconds.

(c) Conversion to TAI calendar dates. In converting to TAI calendar dates, one
has to first add 10 seconds so that the epoch coincides with the start of a TAI
day.

It would appear that a more convenient epoch would be 1970-01-01 00:00:00 TAI.
This would eliminate the awkward adjustments by 10 seconds when converting to
UTC and to TAI calendar dates.

Furthermore, in many implementations current-second will be implemented as the
number of seconds since the POSIX epoch excluding leap seconds (e.g., the value
returned by clock() or a similar system call) plus a constant. Again, this
constant is not the widely-disseminated difference between UTC and TAI but
rather is this difference minus 10 seconds. I have to date seen two
implementations of current-time and both initially made the mistake of using 34
seconds for early 2012 rather than 24 seconds.

I submit that using an epoch of 1970-01-01 00:00:00 TAI is in most cases more
convenient and likely to lead to fewer programming errors. It will be less
convenient on systems that already use the "TAI-10" timescale, but these are
much less common.


_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports