This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

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

2012-04-05 09:59:36
WG1 - Core
2012-03-12 06:33:58

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


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:

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.


The WG voted to adopt this proposal. A formal response has been sent.