Christian.Huitema@mirsa.inria.fr (Christian Huitema) (08/29/90)
A bug appeared recently in our gateway software between RFC and X.400; the bug was traced to the occurence of "random" or rather "unexpected" time zone indicators in the RFC "date" component of the "Received" fields. The bug was corrected by mapping all these unexpected zones to GMT -- which is indeed sort of disgusting. By mixing relevant RFC with a message from Mabry Tyson dated 15 Jan 90 and a message from Jon Postel dated 4 May 1986 (both message were sent to me by Frank Elsner), I have been able to construct the following list of time zones. Note that I only need to perform one way mappings, from time zone to "Delta to UT", and that I am not interested in the reverse mapping. Thus, I want to build up a list which appears as complete as possible. Also note that the deltas follow the X.400 convention, e.g. NY is -0500. Comments are welcomed! Christian Huitema --------------------- "+0000", "GMT", /* Greenwich Mean Time */ "+0000", "UT", /* Universal Time */ "+0100", "BST", /* British Summer Time */ "+0100", "CET", /* Central European Time */ "+0100", "DNT", /* ?? From Denmark */ "+0100", "FWT", /* French Summer Time) */ "+0100", "MET", /* Middle Europe Time */ "+0100", "MEWT", /* Middle Europe Winter Time */ "+0100", "MEZ", /* Middle Europe Zone(?) From Bern, Switzerland */ "+0100", "NOR", /* ?? From Norway */ "+0100", "SWT", /* Swedish Winter Time */ "+0100", "WET", /* Western European Time */ "+0200", "EET", /* Eastern European Time, USSR Zone 1 */ "+0200", "FST", /* French Winter Time */ "+0200", "MEST", /* Middle Europe Summer Time */ "+0200", "SST", /* Swedish Summer Time */ "+0300", "BT", /* Baghdad Time */ "+0300", "HMT", /* ?? From Greece */ "+0330", "IT", /* Iran Time */ "+0530", "IST", /* Indian Standard Time */ "+0630", "NST", /* North Sumatra Time */ "+0700", "SST", /* South Sumatra Time, USSR Zone 6 */ "+0700", "WAST", /* West Australian Standard Time */ "+0730", "JT", /* Java Time */ "+0800", "CCT", /* China Coast */ "+0800", "WADT", /* West Australian Daylight Saving Time */ "+0830", "MT", /* Moluccas Time */ "+0900", "JST", /* Japan Std Time, USSR Zone 8 */ "+0900", "KST", /* ?? Korea Standard Time */ "+0930", "CAST", /* Central Australian Standard Time */ "+0930", "SAST", /* South Australian Standard Time */ "+1000", "GST", /* Guam Std Time, USSR Zone 9 */ "+1000", "LIGT", /* ?? From Melbourne, Australia */ "+1030", "CADT", /* Central Australian Standard Time */ "+1030", "SADT", /* South Australian Daylight S. Time */ "+1200", "IDLE", /* International Date Line, East */ "+1200", "NZST", /* New Zealand Standard Time (*) */ "+1200", "NZT", /* New Zealand Time */ "+1300", "NZDT", /* New Zealand Daylight Time (*) */ "-0100", "SET", /* ??? */ "-0100", "WAT", /* West Africa */ "-0100", "WAT", /* West Africa Time */ "-0200", "AT", /* Azores Time */ "-0300", "BST", /* Brazil Std Time */ "-0330", "NFT", /* Newfoundland Time */ "-0330", "NST", /* Newfoundland */ "-0400", "AST", /* Atlantic Std Time */ "-0400", "EDT", "-0400", "ZP4", /* GMT +4 hours. */ "-0500", "CDT", "-0500", "EST", /* Eastern Std Time */ "-0500", "ZP5", /* GMT +5 hours. */ "-0600", "CST", /* Central Std Time */ "-0600", "MDT", "-0600", "ZP6", /* GMT +6 hours. */ "-0700", "MST", /* Mountain Std Time */ "-0700", "PDT", "-0800", "PST", /* Pacific Std Time */ "-0900", "YST", /* Yukon Std Time */ "-1000", "AEST", /* Australian Eastern Standard Time */ "-1000", "AHST", /* Alaska-Hawaii */ "-1000", "CAT", /* Central Alaska Time */ "-1000", "EAST", /* East Australian Standard Time */ "-1030", "HST", /* Hawaiian Std Time *Hawaii adopted -1000 in 1947 */ "-1100", "BT", /* Bering Time */ "-1100", "NT", /* Nome Time */ "-1200", "IDLW", /* INternational Date Line, West */
Piet.Beertema@cwi.nl (08/29/90)
Note that I only need to perform one way mappings, from time zone to "Delta to UT" MET DST -> +0200 METDST -> +0200 CET DST -> +0200 CETDST -> +0200 Also note that the deltas follow the X.400 convention, e.g. NY is -0500. Same as RFC822 (par. 5.1, 5.2). Piet
solomon@cs.wisc.edu (Marvin Solomon) (08/30/90)
I've also had occation to try to compile a list of time zones in common use and came up with slightly different results. In addition to NST and AST I have NDT (Newfoundland Daylight Time): -2:30, and ADT (Atlantic Daylight Time): -3:00 I also have HST (Hawaiian Standard Time): -1000 (rather than Hawaii-Alaskan -- I understand it isn't really used in Alaska). For WET (Western European) I have 0 rather than +100 I have different values for Australia: for Western Australia I have WST = +800, WDT= +900 Also note that some time zones are ambiguous: BST can be British Summer Time or Bering Standard Time. I understand that Australia also uses CST and EST (and CDT and EDT?) For SST you have Sweden, I have Singapore (+800) Am I right about any of this or am I all wet?
A.Worsley@cs.ucl.ac.UK (Andrew Worsley) (08/30/90)
Christian Huitema writes: >"-1000", "EAST", /* East Australian Standard Time */ I find it very hard to believe in *ANY* negative offsets for Australia, may be this is Alaska? As Australia is west of New Zealand which is also a positive time offset. and Marvin Solomon replies: .... I understand that Australia also uses CST and EST (and CDT and EDT?) ... Am I right about any of this or am I all wet? You are right. EST= Eastern Standard Time (East of Australia) used in Melbourne which is +1000 (+1100 during day light savings which varies from state to state). Ask kre@munnari.oz.au for more info about time zones in Australia. He is a local expert becuase he had to do a lot of research to for the freely timezone stuff software that was posted to the network a year or two ago. Andrew
Christian.Huitema@mirsa.inria.fr (Christian Huitema) (08/30/90)
Good. Now we have at least five collisions: BST can be either Bering Straight or British Standard; EST can be either Melbourne or Boston; EDT can be either Brisbane or Miami; CST can be either Adelaide or Chicago; CDT can be either Darwin or New-Orleans.. In the absence of a disambiguation algorithm, I intend to apply a "vote by head": Eastern and Central North-America is somewhat more populated than Australia, and the British Isles somewhat more than the Straight of Bering. What I will not try to implement is a recognition of the "domain" mentionned in the "received" field, in order to choose the time zone naming context... Christian Huitema
david@twg.COM ("David S. Herron") (08/31/90)
I recently received some mail from a fella in Namibia and the timezone in the header read "SAST". I assumed this was South Africa Standard Time but the list you posted the other day claimed that was in Australia.. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
enag@ifi.uio.no (Erik Naggum) (08/31/90)
In article <9008300931.AA19045@jerry.inria.fr> Christian.Huitema@mirsa.inria.fr writes: In the absence of a disambiguation algorithm, I intend to apply a "vote by head": Eastern and Central North-America is somewhat more populated than Australia, and the British Isles somewhat more than the Straight of Bering. What I will not try to implement is a recognition of the "domain" mentionned in the "received" field, in order to choose the time zone naming context... I'm somewhat confused. Does this age-old problem apply to the X.400 camp, too? I thought they had done this right, at least. The Internet Host Requirements RFC recommended using numeric only time zones, which, albeit a bit different to read as-is by humans in any given local area, can easily be translated by the user agent into something useful, such as what this corresponds to in local time, or where it was posted from, and what the time is there now. (The age of a message can be important and useful to know when deciding which messages to reply to among many, as is the time at which your reply is going to reach them.) Sorry if I've completely lost track of this discussion, and ask stupid questions. -- [Erik Naggum] Naggum Software; Gaustadalleen 21; N-0371 OSLO; NORWAY I disclaim, <erik@naggum.uu.no>, <enag@ifi.uio.no> therefore I post. +47-295-8622, +47-256-7822, (fax) +47-260-4427
SXKAC%ALASKA.BITNET@cornellc.cit.cornell.edu (Kurt Carlson) (08/31/90)
> From: Marvin Solomon <solomon@cs.wisc.edu> > In addition to NST and AST I have > NDT (Newfoundland Daylight Time): -2:30, and > ADT (Atlantic Daylight Time): -3:00 > I also have HST (Hawaiian Standard Time): -1000 > (rather than Hawaii-Alaskan -- I understand it isn't really used > in Alaska). As I commented privately to Christian Huitema previously, Alaska uses AST/ADT which covers the majority of the state with the exception of the Aluetian Islands. The time equates to Yukon (-9) not Hawaii. Since AST/ADT were not referenced explicitely within RFC822 (which doesn't recognize the world beyond the "continental" United States... I never have figured out exactly which continent Alaska is supposed to be on) we implemented our mailer to use the offset from GMT/UT for messages routed out of Alaska. While we took the "correct" course in using an offset from GMT, that does not preclude the existance of other Alaska mailers or some bureaucrat someday insisting I convert to the accepted AST/ADT abbreviations which will collide us with Atlantic (Greenland/Iceland?)... nor does it preclude some borough or village declaring their own time zone according to the geographic diferential from Greenwich disregarding the State of Alaska definition merging 4 geographic zones into one. I suspect the further one looks, the more collisions one will find between "local" designation for time zones. There may not be a solution to correctly mapping the time zones without (yet another) standard. You may be best advised to take whatever best approaches a documented standard for abbreviations (is there anything else beyond rfc822?) and simply map the numerous others directly as UT... that may encourage others to abide by something resembling a standard. Alternatively, simply use the time you received the message ignoring the post time. Kurt Carlson, University of Alaska <sxkac@alaska.bitnet>
Stef@nrtc.northrop.COM (Einar Stefferud) (08/31/90)
Aw, Shux Christian -- It seems pretty obvious that a .au top level Originator Address is virtually certain not be from Miami, Boston, Chicago, New Oleans, or anywhere in the .us! Also, .uk (or .gb) are pretty sure to not be in alaska, while .edu is pretty certain to not be in the UK (or GB). So why not look at the Origiantors address? Best...\Stef
solomon@cs.wisc.edu (Marvin Solomon) (08/31/90)
> > Aw, Shux Christian -- It seems pretty obvious that a .au top level > Originator Address is virtually certain not be from Miami, Boston, > Chicago, New Oleans, or anywhere in the .us! > > Also, .uk (or .gb) are pretty sure to not be in alaska, while .edu is > pretty certain to not be in the UK (or GB). > > So why not look at the Origiantors address? Best...\Stef > Hi, Stef. Perhaps you missed the beginning of this discussion, but the problem at hand is how to translate an 822 date into something meaningful (like GMT), e.g. to sort messages by time sent, or to convert to X.400. (Then again, perhaps you just forgot to include a smiley face :-). I know of no database that can be used to translate domains into timezones, so looking at the domain, while perhaps helpful to a human user *in some cases*, is of no help whatsoever to the program parsing the date. I say *in some cases* since domains are not necessarily tied to geography: How can I tell that northrop.com is in PDT? Doesn't IBM's Guam office belong under ibm.com (actually, probably really belongs under ibm.ny.us). Is a Delaware corporation necessarily in EDT? Does a Liberian freighter necessarily come from Liberia? Enquiring minds want to know. As Erik Swiggum points out, this discussion is probably on the wrong list (except possibly for the bit about translating from rfc822 to X.400). --Marvin
SOLOMON%CS.WISC.EDU@cunyvm.cuny.edu (09/02/90)
RFC-822-Headers: X-Mailer: ELM [version 2.2 PL10] BODY TYPE: IA5TEXT > > Aw, Shux Christian -- It seems pretty obvious that a .au top level > Originator Address is virtually certain not be from Miami, Boston, > Chicago, New Oleans, or anywhere in the .us! > > Also, .uk (or .gb) are pretty sure to not be in alaska, while .edu is > pretty certain to not be in the UK (or GB). > > So why not look at the Origiantors address? Best...\Stef > Hi, Stef. Perhaps you missed the beginning of this discussion, but the problem at hand is how to translate an 822 date into something meaningful (like GMT), e.g. to sort messages by time sent, or to convert to X.400. (Then again, perhaps you just forgot to include a smiley face :-). I know of no database that can be used to translate domains into timezones, so looking at the domain, while perhaps helpful to a human user *in some cases*, is of no help whatsoever to the program parsing the date. I say *in some cases* since domains are not necessarily tied to geography: How can I tell that northrop.com is in PDT? Doesn't IBM's Guam office belong under ibm.com (actually, probably really belongs under ibm.ny.us). Is a Delaware corporation necessarily in EDT? Does a Liberian freighter necessarily come from Liberia? Enquiring minds want to know. As Erik Swiggum points out, this discussion is probably on the wrong list (except possibly for the bit about translating from rfc822 to X.400). --Marvin
STEF%NMA.COM@cunyvm.cuny.edu (09/02/90)
Hi Marvin -- NO -- I have been following from the beginning. Yes, I might have helped by including a smiley face, but I was seriously making some obsevations about the specific cases that Christain saiud he would handle in a very arbitrary way without looking at any other information, such as the .toplevel domain of the originator. It seems to me that in the cases where he wishes to be totally arbirtrary, that the information in the originators toplevel domain is relevant and close to conclusinve. That is all that I intended to convey. I do not suggest a general tie between any time zone and any toplevel name, for all time zones and all toplevel names. Cheers...\Stef;-)
jklein@faui43.informatik.uni-erlangen.de (Juergen Kleinoeder) (09/05/90)
Christian.Huitema@mirsa.inria.fr (Christian Huitema) writes: as it was a problem with the old System V.2 to have more than 3 letters in the timezone-field there has been a proposal for the european daylight saving times several years ago. >"+0100", "MET", /* Middle Europe Time */ "+0200", "MED", /* Middle European Daylight Time */ and similar "WED" for "WET DST" and "EED" for "EET DST". Juergen Kleinoeder University of Erlangen Germany
kre@cs.mu.oz.au (Robert Elz) (09/10/90)
In article <9008300931.AA19045@jerry.inria.fr>, Christian.Huitema@mirsa.inria.fr (Christian Huitema) writes: > EST can be either Melbourne or Boston; yes. > EDT can be either Brisbane or Miami; No, in Brisbane it would be EST ... (Eastern Summer Time). That is, EST can be -0500 +1000 or +1100 (and possibly more). > CST can be either Adelaide or Chicago; yes. > CDT can be either Darwin or New-Orleans.. No, there's no daylight saving in Darwin .... (in Adelaide it would be CST I believe - same reason as above). Sometimes Australians (in some weird deference to the US) use AEST (etc, but still +1000 or +1100) which only makes sense if compared with USEST. Some particularly ignorant systems use AESST (which is an onymoron .. "standard summer time" ??) > In the absence of a disambiguation algorithm, I intend to apply a "vote > by head": Eastern and Central North-America is somewhat more populated > than Australia, I'd do that too, forget the "originates from Australia" idea, that's too much work (and still doesn't disambiguate "Standard" from "Summer" unless you also want to look at the date value, and then decide whether summer time would have been used at the appropriate date -- good luck. What's more, in RFC822, EST is defined to be -0500, putting EST there and meaning something else is simply wrong. While attempting to interpret these things in some meaningful way is admirable, I'm not sure itw worth the bother really, RFC822 allows just 5 (or so) alphabetic timezone strings (excluding the deprecated US military one character trash) - by all means translate those ones, I'd just treat the rest as meaning GMT (you could claim "protocol error" and bounce the message, but that would be a little harsh). If you do add all this, please arrange to read the mapping from a config file, don't compile it in anywhere, expecting anyone to actually figure out what all the zone names are, and then decide which of the ambiguous mappings is more important in any particular case (if we actually used EST in messages, I would prefer it to be +1000 (or +1100) here, but in the rest of the world making it -0500 would make more sense). kre