abe@mace.cc.purdue.edu (Vic Abell) (05/18/91)
Does anyone have a list of the possible time zone abbreviations that can appear in mail Date: lines? I've gleaned about 30 of them from various BSD timezone() sources and other deductions -- e. g., TST is Turkish Standard Time, ITA is the Italian time zone abbreviation -- but I'm stumped over a number of ones I have found. For example, where is SLT? My local reference librarians tell me it is an interesting question. :-)
Christopher-Vance@adfa.oz.au (Christopher JS Vance) (05/20/91)
In article <7495@mace.cc.purdue.edu> abe@mace.cc.purdue.edu (Vic Abell) writes: | Does anyone have a list of the possible time zone abbreviations that | can appear in mail Date: lines? I've gleaned about 30 of them from | various BSD timezone() sources and other deductions -- e. g., TST is | Turkish Standard Time, ITA is the Italian time zone abbreviation -- | but I'm stumped over a number of ones I have found. For example, | where is SLT? Not again... Sigh. :-( The correct answer is to use numeric timezones only. They are sanctioned by international standards. As for the Internet, RFC1123 section 5.2.14 says: 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5 The syntax for the date is hereby changed to: date = 1*2DIGIT month 2*4DIGIT All mail software SHOULD use 4-digit years in dates, to ease the transition to the next century. There is a strong trend towards the use of numeric timezone indicators, and implementations SHOULD use numeric timezones instead of timezone names. However, all implementations MUST accept either notation. If timezone names are used, they MUST be exactly as defined in RFC-822. The military time zones are specified incorrectly in RFC-822: they count the wrong way from UT (the signs are reversed). As a result, military time zones in RFC-822 headers carry no information. Finally, note that there is a typo in the definition of "zone" in the syntax summary of appendix D; the correct definition occurs in Section 3 of RFC-822. And RFC822 section 5.1 says (in part): zone = "UT" / "GMT" ; Universal Time ; North American : UT / "EST" / "EDT" ; Eastern: - 5/ - 4 / "CST" / "CDT" ; Central: - 6/ - 5 / "MST" / "MDT" ; Mountain: - 7/ - 6 / "PST" / "PDT" ; Pacific: - 8/ - 7 / 1ALPHA ; Military: Z = UT; ; A:-1; (J not used) ; M:-12; N:+1; Y:+12 / ( ("+" / "-") 4DIGIT ) ; Local differential ; hours+min. (HHMM) My local timezone in normal time is +1000 and in (the southern) summer it is +1100. The letter abbreviation used in my country for both of these is EST, which doesn't mean what EST means to you. It's a can of worms, and alphabetic time zone abbreviations should be made to disappear as quickly as possible. Any zone names other than the ones listed above in RFC822 are invalid as far as internet hosts are concerned because of RFC 1123. If you use MH, make sure it's compiled with ATZ off. And if you use sendmail later than 5.61 it should do the right thing too. The incorrect answer is to add the following to your list: "EST" / "EST" Eastern +10 / +11 "CST" / "CST" Central +9.5 / +10.5 "WST" Western +8 Now doesn't that make things clearer :-). Yet another answer: people can set their timezone names to just about anything, and there's not necessarily any correlation with your intuitive feeling as to what they might mean. -- Christopher