Ticket 357: Formal Comment: The epoch of current-second should be 1970-01-01 00:00:00 TAI.

Formal Comment

Submitter's Name: Alan Watson

Submitter's Email Address: alan at alan-watson dot org

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.