History of time_t (was: 2000 bug ? GO LINUX) 
Author Message
 History of time_t (was: 2000 bug ? GO LINUX)

A couple of weeks ago in two of these newsgroups, David Fox asked:

} Why was time_t made to be signed? It doesn't appear to make any sense:
} it won't give sensible negative values anyway.

And I (Mark Brader) answered:
| Presumably because, in C, the result of an arithmetic operation has the
| same type as the operands.  Suppose time_t was a 32-bit unsigned type and
| you did
|       extern time_t t1, t2;
|       time_t diff = t2 - t1;
| If t1 was 100 seconds later than t2, you would like diff to be -100
| ...
| With the coming of ANSI C, the type time_t was made part of the C
| standard, but its representation was not specified.  Rather than the
| direct subtraction of time_t's that works on UNIX-derived systems,
| the standard provides a library function ... difftime (t2, t1) ...

And then added in a followup:
| The fact that subtraction produces a useful result may well have been
| a factor in why time_t *remained* a signed type as UNIX developed, but
| I don't know if it really was or not.  (I'll ask Dennis Ritchie in email
| and get back to you here if he tells me.)
| There's a much stronger reason why a signed type was used originally:
| when the "long" type was first added to C, *there was no unsigned long
| type*.  Look in K&R1 -- the only unsigned type in there unsigned itself,
| a.k.a. unsigned int.  And on the PDP-11, which was then the most important
| C platform, this was only 16 bits.  So it was natural to use the signed
| long type for times.
| (And before *that*, they used an array of 2 ints.  The fact that functions
| like ctime() use only the value of a time_t argument but require a pointer
| to it as argument is a holdover from that era.)

Well, I did hear back from Dennis Ritchie, and with his permission I'm
posting the email here.  I've also added comp.lang.c.moderated to the
list of newsgroups and directed followups there.

Dennis writes:

# I don't recall any serious thought about changing time_t to
# unsigned.   To the extent it was thought about, I recall these
# aspects:
# 1) If I'm not dead by the epoch this becomes a problem, I will
# certainly not care about the issue any more.
# 2) When the problem occurs, the obvious and simple fix is to declare
# that time_t is now unsigned, fix the minority of programs that do
# signed comparisons, and relink the others.   As you point out,
# ANSI has in theory fixed the time-difference problem well in
# advance.
# 3) There was a certain attraction to the ability to represent
# dates within my lifetime (which didn't start in 1970)--
# albeit I can't recall that this possibility has been used.
# 4) Even on reflection today, the problem is still sufficiently
# far in the future that it's hard to imagine things won't have
# changed a lot.  I mean, once all the computing people have
# worked really hard to make 2000 work, they have a bit
# of time to relax before ramping up to the big Y20.38K effort.
#       Dennis

So, now we know.

SoftQuad Inc., Toronto  |  go with UNIX." -- "/aur" magazine, April-May '89

My text in this article is in the public domain.

Thu, 08 Jul 1999 03:00:00 GMT  
 [ 1 post ] 

 Relevant Pages 

1. History of time_t (was: 2000 bug ? GO LINUX)

2. time_t time and Year 2000

3. time_t time and Year 2000

4. SQL server 2000 , a bug related to ODBC DSN ADO related

5. Suspected bug in MS Jet or Access 2000 SQL/VBA engine

6. BUG REPORT (03 03 2000) in Visual C++ 6 (sp3) : Custom Build Step

7. Visual C++ 6.0 bug on Windows 2000?

8. Font/TextBox bug in 2000 and XP

9. BUG: OutputDebugString Output Fails to Appear on Windows 2000

10. Bugs in Windows 2000 with MDI Application?!?

11. CFileDialog and Windows 2000 Bug ?

12. Windows 2000 bug...


Powered by phpBB® Forum Software