cmv@ihlpm.ATT.COM (C M Votava) (12/01/87)
A friend of mine was flipping through the libc code that handles time on the
unix machine, namely "/usr/src/lib/libc/port/gen/ctime.c" and came across the
following excerpt of code:
/*
* day is the day number.
* generate day of the week.
* The addend is 4 mod 7 (1/1/1970 was Thursday)
*/
xtime.tm_wday = (day + 7340036L) % 7;
The obvious question is what the hell does 7340036 represent? Well, first
some background; we all know that unix keeps track of the number of seconds
since the epoch (January 1, 1970); and at this point in the code, "day"
contains the number of days since then (time/86400). Here it's trying to figure
the day of the week as a number from 0-6 where 0=Sunday. Now a simple way of
doing this is with "(day+4)%7" so why was 7340036 used?
Here are some facts that I found out:
1). This same number is used in many versions of unix. I've verified it on
unix running on a maxi, 3B20D, and 3B20S.
2.) I expect this code is descended from older code.
3.) Much of the surrounding code tries to handle (or guard against) negative
numbers.
4.) The number above can be broken down as follows:
binary = 0111 0000 0000 0000 0000 0100
octal = 034000004
decimal = 7340036
hex = 700004
5.) I think the following math is correct:
break up the binary of 7340036 into binary
0111 0000 0000 0000 0000 0100 (0x700004)
get binary form of largest 23 bit 1's compliment number
0111 1111 1111 1111 1111 1111 (0x7fffff)
add them together with 1's compliment arithmetic you get
0111 0000 0000 0000 0000 0100 (0x700004)
Pretty neat trick if I've done my 1's compliment arithmetic correctly huh?
Is this what was intended when the number was chosen, or am I on the wrong
track? Another track that was suggested is:
day of week = (#of days + 4)% 7
dow = #od % 7 + 4 % 7
dow = #od % 7 + n % 7
where n % 7 = 4
If you wish to record a valid number prior to 1/1/70 then #od
would be negative. If you want a positive number, then you need to
add a sufficiently big n. 7340036 % 7 = 4.
7340036 is about 20100 years. The selection of n seems
to be arbitrary corresponding to a long time ago and sufficiently
confusing to mind boggle hackers like us.
I like this track too, and wonder if the date corresponding to 7340036 might be
the next epoch? What we need is for someone "in the know" to give us a hand!
Any help is appreciated, a result posting will follow if there is interest!
Craig Votava
AT&T Bell Labs, Naperville IL
[ihnp4!]ihlpm!cmv