home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / perl / 4870 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.1 KB  |  61 lines
  1. Newsgroups: comp.lang.perl
  2. Path: sparky!uunet!nic.unh.edu!anchor.unh.edu!pas
  3. From: pas@anchor.unh.edu (Paul A Sand)
  4. Subject: Re: bug in ctime.pl?
  5. Message-ID: <1992Jul22.130507.12141@nic.unh.edu>
  6. Sender: news@nic.unh.edu (USENET News System)
  7. Organization: University of New Hampshire
  8. References: <1992Jul21.201121.15732@nic.unh.edu> <BrryKL.Msx@rahul.net>
  9. Date: Wed, 22 Jul 1992 13:05:07 GMT
  10. Lines: 49
  11.  
  12. In article <BrryKL.Msx@rahul.net> dhesi@rahul.net (Rahul Dhesi) writes:
  13. >In <1992Jul21.201121.15732@nic.unh.edu> pas@anchor.unh.edu (Paul A Sand) 
  14. >wonders if ctime.pl should do $year += 1900 instead of
  15. >
  16. >>     $year += ($year < 70) ? 2000 : 1900;
  17. >
  18. >Both are identical at this time.  However, some time in the next
  19. >century, when the 32-bit value of Unix time overflows and time begins
  20. >running backwards, the two will give different results.  Whichever form
  21. >gives a value closer to the truth will then be preferable; I believe
  22. >the longer form will be the one.
  23.  
  24. Looking at the code in ctime.pl, I think you are (in effect) claiming
  25. that the Perl gmtime()/localtime() functions are broken, or will break
  26. sometime next century.  (More specifically: they will start returning
  27. the wrong value for the 'years since 1900' element of their return
  28. values. As far as I can tell, that's what they are supposed to do.) I
  29. haven't tested that, but I don't think that's standard behavior for the
  30. analogous C functions.
  31.  
  32. Perhaps I should have been more specific about what I regarded
  33. as peculiar.  Here in lovely New Hampshire, this C program:
  34.  
  35.     #include <time.h>
  36.     main()
  37.     {
  38.      time_t t;
  39.      t = 0;
  40.      printf("%s", ctime(&t));
  41.     }
  42.  
  43. prints:
  44.  
  45.     Wed Dec 31 19:00:00 1969
  46.  
  47. (i.e., midnight in Greenwich) But this:
  48.  
  49.     % perl -e 'require "ctime.pl"; print &ctime(0);'
  50.  
  51. prints:
  52.  
  53.     Wed Dec 31 19:00:00 2069
  54.  
  55. I think my proposed change would (at least) make the Perl and C
  56. versions of ctime() behave alike.
  57. -- 
  58. -- Paul A. Sand           | I learned to put the [toilet] seat down...it
  59. -- Univ. of New Hampshire | makes you look like a warm, caring, sensitive
  60. -- pas@kepler.unh.edu     | human being. (Prof. R. Noble, from r.h.f.)
  61.