home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / mail / headers / 254 < prev    next >
Encoding:
Text File  |  1992-08-20  |  3.1 KB  |  85 lines
  1. Newsgroups: comp.mail.headers
  2. Path: sparky!uunet!usc!sdd.hp.com!nigel.msen.com!math.fu-berlin.de!informatik.tu-muenchen.de!LRZnews!cd1.lrz-muenchen.de!a2824as
  3. From: a2824as@cd1.lrz-muenchen.de (Michael Storz)
  4. Subject: Re: New date format (year) ?
  5. Message-ID: <1992Aug21.075050.28039@news.lrz-muenchen.de>
  6. Sender: news@news.lrz-muenchen.de (Mr. News)
  7. Reply-To: Michael.Storz@lrz.lrz-muenchen.dbp.de
  8. Organization: Leibniz-Rechenzentrum Muenchen, Germany
  9. References:  <129@bull.bull.fr>
  10. Date: Fri, 21 Aug 1992 07:50:50 GMT
  11. Lines: 72
  12.  
  13. In article <129@bull.bull.fr>, jpaul@gwx400A.bull.fr writes:
  14. |> 
  15. |> -- 
  16. |> 
  17. |> Hello every body,
  18. |> 
  19. |>   I have seen that on sendmail 5.65 it seems that the year in the date field 
  20. |>   is writen with 4 digits :
  21. |> 
  22. |> ex :
  23. |> in 5.61 :
  24. |> Tue, 18 Aug 92 12:08:02 +0200
  25. |> 
  26. |> in 5.65 :
  27. |> Tue, 18 Aug 1992 12:08:02 +0200
  28. |> 
  29. |> I presume this is not a hazard : year 2000 is comming and it is probably the 
  30. |> reason of that change.
  31. |> 
  32. |> But this causes me a problem on a gateway which is not able to manage that 
  33. |> format. And I would like to know if there an RFC or some think concerning 
  34. |> this before submitting the problem to the gateway's programmer.
  35.  
  36.  
  37. The answer is: RFC 1123
  38.  
  39.       5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5
  40.  
  41.          The syntax for the date is hereby changed to:
  42.  
  43.             date = 1*2DIGIT month 2*4DIGIT
  44.  
  45.          All mail software SHOULD use 4-digit years in dates, to ease
  46.          the transition to the next century.
  47.  
  48.          There is a strong trend towards the use of numeric timezone
  49.          indicators, and implementations SHOULD use numeric timezones
  50.          instead of timezone names.  However, all implementations MUST
  51.          accept either notation.  If timezone names are used, they MUST
  52.          be exactly as defined in RFC-822.
  53.  
  54.          The military time zones are specified incorrectly in RFC-822:
  55.          they count the wrong way from UT (the signs are reversed).  As
  56.          a result, military time zones in RFC-822 headers carry no
  57.          information.
  58.  
  59.          Finally, note that there is a typo in the definition of "zone"
  60.          in the syntax summary of appendix D; the correct definition
  61.          occurs in Section 3 of RFC-822.
  62.  
  63. Most software is not able to handle this at the moment, but it begins to
  64. change.
  65.  
  66. |> 
  67. |> Thanks per advance,
  68. |> Best regards,
  69. |> --------------------------------     Jean-Paul OLIVIER
  70. |> Email : J.P.Olivier@frso.bull.fr    BULL.S.A.
  71. |> Phone : (1) 49 45 50 40            20, rue Dieumegard
  72. |> bullcom : 222 5040            93406 SAINT-OUEN CEDEX
  73. |> fax : (1) 49 45 53 36            France
  74.  
  75. -- 
  76.  
  77. Michael Storz
  78. ================================================================================
  79.                                       !   X.400 : G=michael;S=storz;OU1=lrz;
  80.    Leibniz-Rechenzentrum              !           P=lrz-muenchen;A=dbp;C=de
  81.    Barer Str. 21                      !   RFC822: storz@lrz.lrz-muenchen.dbp.de
  82.    8000 Muenchen 2                    !   Fax   : ++ 49 89 2809460
  83.    Germany                            !   Tel   : ++ 49 89 2105 7420
  84. ================================================================================
  85.