home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / perl / 4895 < prev    next >
Encoding:
Text File  |  1992-07-22  |  1.7 KB  |  42 lines
  1. Newsgroups: comp.lang.perl
  2. Path: sparky!uunet!destroyer!sol.ctr.columbia.edu!ucselx!gdwest!good
  3. From: good@gdwest.gd.com (David L. Good)
  4. Subject: Re: bug in ctime.pl?
  5. Message-ID: <1992Jul22.234720.19969@gdwest.gd.com>
  6. Organization: General Dynamics Corp.
  7. References: <1992Jul21.201121.15732@nic.unh.edu>
  8. Date: Wed, 22 Jul 1992 23:47:20 GMT
  9. Lines: 31
  10.  
  11. In article <1992Jul21.201121.15732@nic.unh.edu> pas@anchor.unh.edu (Paul A Sand) writes:
  12. >Based on some peculiar behavior, I looked at the ctime.pl library
  13. >file. It contains the line:
  14. >
  15. >     $year += ($year < 70) ? 2000 : 1900;
  16. >
  17. >where $year is one of the elements returned from gmtime() or
  18. >localtime(). Looking at the definitions of what *those* return,
  19. >it seems the statement should be simply:
  20. >
  21. >    $year += 1900;
  22. >
  23. >Or am I missing something subtle?
  24.  
  25. Well, if as you state (and the man pages for both our Suns and HPs) the tm
  26. structure used in C uses years since 1900 for tm_year, the original line
  27. will still work.  In fact, $year will _never_ be less than 70 (unless
  28. somebody sets their clock back for kicks or to be able to use time-bombed
  29. vendor software :-), so there's no problem.  If, on the other hand, someone
  30. has a brain-dead UNIX (brain-dead, because there's no reason not to return
  31. "years since 1900" instead of "years since the beginning of the century"
  32. since there's plenty of room in even an 8-bit "int" for numbers greater
  33. than 99) that would return "0" for tm_year on Jan 1, 2000, the first line
  34. will _still_ work (at least for another 100 years :-). 
  35.  
  36. So...although it may seem a waste, ctime.pl is probably doing the right thing.
  37.  
  38. -- 
  39. David Good                                               good@gdwest.gd.com
  40.  
  41.                  This space intentionally left blank.
  42.