home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / mail / headers / 252 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  2.1 KB
  1. Path: sparky!uunet!gumby!wupost!waikato.ac.nz!comp.vuw.ac.nz!asjl
  2. Newsgroups: comp.mail.headers
  3. Subject: Re: New date format (year) ?
  4. Message-ID: <BtB7HE.GoB@comp.vuw.ac.nz>
  5. From: Andy.Linton@comp.vuw.ac.nz (Andy Linton)
  6. Date: Fri, 21 Aug 1992 01:15:14 GMT
  7. Sender: news@comp.vuw.ac.nz (News Admin)
  8. References: <129@bull.bull.fr>
  9. Organization: Dept of Comp Science, Victoria Uni, Wellington, NEW ZEALAND
  10. Nntp-Posting-Host: bats.comp.vuw.ac.nz
  11. Lines: 51
  12.  
  13.  
  14. In article <129@bull.bull.fr>, jpaul@gwx400A.bull.fr writes:
  15. |> 
  16. |> -- 
  17. |> 
  18. |> Hello every body,
  19. |> 
  20. |>   I have seen that on sendmail 5.65 it seems that the year in the date field 
  21. is writen with 4 digits :
  22. |> 
  23. |> ex :
  24. |> in 5.61 :
  25. |> Tue, 18 Aug 92 12:08:02 +0200
  26. |> 
  27. |> in 5.65 :
  28. |> Tue, 18 Aug 1992 12:08:02 +0200
  29. |> 
  30. |> I presume this is not a hazard : year 2000 is comming and it is probably the
  31. reason of that change.
  32. |> 
  33. |> But this causes me a problem on a gateway which is not able to manage that 
  34. format. And I would like to know if there an RFC or some think concerning this
  35. before submitting the problem to the gateway's programmer.
  36.  
  37.  
  38. In RFC 1123 - Requirements for Internet Hosts -- Application and Support:
  39.  
  40. 5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5
  41.  
  42.          The syntax for the date is hereby changed to:
  43.  
  44.             date = 1*2DIGIT month 2*4DIGIT
  45.  
  46.  
  47.          All mail software SHOULD use 4-digit years in dates, to ease
  48.          the transition to the next century.
  49.  
  50.          There is a strong trend towards the use of numeric timezone
  51.          indicators, and implementations SHOULD use numeric timezones
  52.          instead of timezone names.  However, all implementations MUST
  53.          accept either notation.  If timezone names are used, they MUST
  54.          be exactly as defined in RFC-822.
  55.  
  56.          The military time zones are specified incorrectly in RFC-822:
  57.          they count the wrong way from UT (the signs are reversed).  As
  58.          a result, military time zones in RFC-822 headers carry no
  59.          information.
  60.  
  61.          Finally, note that there is a typo in the definition of "zone"
  62.          in the syntax summary of appendix D; the correct definition
  63.          occurs in Section 3 of RFC-822.
  64.