?

Log in

No account? Create an account

fanf

Nerdy trivia about Unix time_t

« previous entry | next entry »
22nd Nov 2014 | 17:26

When I was running git-cvsimport yesterday (about which more another time), I wondered what were the nine-digit numbers starting with 7 that it was printing in its progress output. After a moment I realised they were the time_t values corresponding to the commit dates from the early 1990s.

Bert commented that he started using Unix when time_t values started with an 8, which made me wonder if there was perhaps a 26 year ambiguity - early 1970s or mid 1990s?. (For the sake of pedantry - I don't really think Bert is that old!)

So I checked and time_t = 80,000,000 corresponds to 1972-07-14 22:13:20 and 90,000,000 corresponds to 1972-11-07 16:00:00. But I thought this was before modern time_t started.

Page 183 of this very large PDF of the 3rd Edition Unix manual says:

TIME (II)                  3/15/72                  TIME (II)

NAME         time -- get time of year

SYNOPSIS     sys time / time = 13
             (time r0-r1)

DESCRIPTION  time returns the time since 00:00:00, Jan. 1,
             1972, measured in sixtieths of a second.  The
             high order word is in the rO register and the
             low order is in the r1.

SEE ALSO     date(I), mdate(II)

DIAGNOSTICS  --

BUGS         The time is stored in 32 bits.  This guarantees
             a crisis every 2.26 years.

So back then the 800,000,000 - 900,000,000 period was about three weeks in June 1972.

The 4th Edition Unix manual (link to tar file of nroff source) says:

TIME (II)                   8/5/73                   TIME (II)

NAME         time -- get date and time

SYNOPSIS     (time = 13)
             sys  time
             time(tvec)
             int tvec[2];

DESCRIPTION  Time returns the time since 00:00:00 GMT, Jan. 1,
             1970, measured in seconds. From asm, the high
             order word is in the r0 register and the low
             order is in r1. From C, the user-supplied vector
             is filled in.

SEE ALSO     date(I), stime(II), ctime(III)

DIAGNOSTICS  none

I think the date on that page is a reasonably accurate indicator of when the time_t format changed. In the Unix manual, each page has its own date, separate from the date on the published editions of the manual. So, for example, the 3rd Edition is dated February 1973, but its TIME(II) page is dated March 1972. However all the 4th Edition system call man pages have the same date, which suggests that part of the documentation was all revised together, and the actual changes to the code happened some time earlier.

Now, time_t = 100,000,000 corresponds to 1973-03-03 09:46:40, so it is pretty safe to say that the count of seconds since the epoch has always had nine or ten digits.

| Leave a comment | Share

Comments {1}

Peter Maydell

from: pm215
date: 22nd Nov 2014 23:23 (UTC)

In 4th Ed the relevant code is in nsys/ken/clock.c, where the clock interrupt (60Hz, US mains frequency) increments the time[0]:time[1] count every 60 interrupts, more or less:
	if(++lbolt >= 60) {
		if((ps&0340) != 0)
			return;
		lbolt =- 60;
		if(++time[1] == 0)
			++time[0];
The time() syscall then just copies the current values of time[0]:time[1] to the user's registers.

The only earlier extant kernel code than this is 1st Ed, which is in assembly (in file u4.s), and just increments the time variable pair unconditionally on every clock interrupt:

clock: / interrupt from 60 cycle clock
       mov     r0,-(sp) / save r0
       tst     *$lks / restart clock?
       mov     $s.time+2,r0 / increment the time of day
       inc     (r0)
       bne     1f
       inc     -(r0)
1:
I wouldn't be surprised if changing the frequency of time() was one of the things that happened in the asm-to-C conversion (given that 3rd Ed was also asm).

Reply | Thread