🚀 go-pugleaf

In article <630@magnus.Hotline.Com> levin@magnus.Hotline.Com (Michael M Levin) writes:
} In article <9002060315.AA10418@xenna.Xylogics.COM> loverso@XYLOGICS.COM (John Robert LoVerso) writes:
} >Hmmm - is this date-parsing code based upon something like unctime(), of
} >B news?  If not, that code already parses lots of different date formats.
} >If you've got additional formats, you could add it to unctime() and hand
} >it back to the rest of the world...
} 
} Me thinks, perhaps, that we are going to find ourselves beating the entire
} timezone issue to death, since there are NO real standards recognized by
} the 'entire civilized world'.

Just to clarify a point:  The standard to which Mush adheres (or attempts
to) is RFC822, Standard for the Format of ARPA Internet Text Messages.
(Mush will also eventually support X.400 format if that is different -- I
have yet to obtain a copy of the X.400 specs, so I can't say.)  The format
specified by RFC822 is:

	Day, Date Month Year Hour:Minute:Second Timezone

where "Day," is optional.  Day and Month are 3-letter abbreviations; Date,
Year, Hour, Minute, and Second are two digits each; and Timezone is either
an offset from Universal Time (GMT) or a short list of North American 3-
letter timezone abbreviations.  Offsets from UT are of the form -HHMM or
+HHMM, e.g. PST is -0800, and Newfoundland is (I think) -0330 (just to
show that the minutes are indeed necesary).

Obviously, this doesn't cover everybody.  Though almost everyone who is
not using X.400 nominally complies with 822, there are a number of minor
variations (omitting the comma after Day, using a 4-digit Year, omitting
the Seconds, swapping the places of Date and Month, etc.) and there are
lots of 3- 4- and 5-letter timezone abbreviations outside NA.  Mush has
so far avoided dealing with the time zone question (hence my original
posting) but it handles all the other variations.

} I believe that a slightly different approach
} is in order-  like, maybe, deciding on just what the OFFICIAL standard
} really ought to be (such as the -0800 format), and if there really isn't
} any pressing reason, _maybe_ just decide on using a header field which is
} called by a slightly different name-- like "Std-time: ", which could then
} be expressed in Greenwich format.

In article <5D01C5E2E4@crdos1> davidsen@crdos1.crd.ge.com writes:
} 
}   I doubt that anything which depends on other people doing things to
} their mailer is going to find a lot of non-compliance. I would be much
} happier having a really strong date interpreter on my end than expecting
} people to add another field to their headers.

Bill has the right idea once you delete "non-" from that first sentence.  
However, I don't think its worthwhile for Mush to go so far as parsing
some of the really outlandish forms.  No mailer is going to generate
"Saturday, February Third, Nineteen Ninety, Twelve Fifty-Seven Thirteen
Post Meridian, Pacific Standard Time".  I'll admit that Mush's present
date parser could stand improvement, but it accepts every date format
that has been reported since Mush first appeared.
-- 
Bart Schaefer          "February.  The hangnail on the big toe of the year."
                                                                    -- Duffy

schaefer@cse.ogi.edu (used to be cse.ogc.edu)