home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v6 / text0038.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  1.5 KB
  1. From: dan@BBN-PROPHET.ARPA 
  2. Date:     Thu, 7 Aug 86 10:24:40 EDT
  3.  
  4. I agree that time_t need not be able to represent times before 1970.
  5. However, I think it's rather short-sighted to say that time_t should never
  6. have its high-order bit set.  That restricts it to representing times
  7. before January 2038.  "UNIX will be dead by then!" you say; well, people
  8. have been predicting the death of Fortran and COBOL for a long time now,
  9. and it still hasn't happened, nor does it show any sign of happening.  In
  10. UNIX's case the fact that it's the first portable operating system is
  11. likely to cause it to continue to exist in some form for MANY years.  Even
  12. if UNIX itself doesn't last until 2038, it will certainly last long enough
  13. that application programmers will find it useful to be able to store and
  14. manipulate future time values later than 2038.  They would undoubtedly
  15. appreciate it greatly if the system library routines supplied with UNIX
  16. worked for those time values.
  17.  
  18. Personally I believe that time_t ought to be an unsigned long, rather than
  19. signed, but that would probably break a lot of existing code.  Still, we
  20. should avoid later problems by specifying that library routines that work
  21. with time_t values should treat it as unsigned, and should work for the
  22. entire range of possible values.  This at least makes it possible for
  23. careful programmers to get their code right.
  24.  
  25. Most of the time-related facilities in UNIX have long been marked by
  26. an amazing short-sightedness.  Let's not perpetuate it.
  27.  
  28.     Dan
  29.  
  30. Volume-Number: Volume 6, Number 39
  31.  
  32.