schaefer@ogicse.ogc.edu (Barton E. Schaefer) (02/06/90)
In article <7129@ogicse.ogc.edu> I wrote: } In article <3257@taux01.UUCP> crehta@taux01.nsc.com (Ran Ever-Hadani) writes: } } How hard should it be to fix the folder sort-by-date to take } } time zones into consideration? } } Mush currently does absolutely *nothing* with time zones -- it doesn't } even store them in its internal representation of the date. I've begun } working on some code for timezones but it isn't anywhere near finished. OK, folks, I need some help here. What follows is a list of all the date formats mush understands. Some of them have time zone fields, some appear not to. All were reported by users of mush at one time or another. I'll run through the ones that I know have TZ first, to give you an idea what I'm after, and then if you recognize any of the other formats and can tell me if and where they give a TZ -- probably at the far right somewhere, but I can't be sure -- we'll be one step closer to doing this right. First comes mush's comment-text description of the format, and then some reconstructions as best I can do them -- I've never seen most of these. === The formats that have time zones. Note that we've had complaints about formats that lack a seconds field in the time, so we have to check for both cases if we scan past a time field looking for a timezone. --- * day_name month_name day_number time timezone year_number Mon Feb 5 14:05:57 PST 1990 Mon Feb 5 14:05:57 -0800 1990 Mon Feb 5 14:05 PST 1990 (This should be good 'ol ctime, but somebody mangles it anyway.) --- * day_number month_name year_number time timezone ... 5 Feb 1990 14:05:57 PST 5 Feb 1990 14:05:57 -0800 5 Feb 1990 14:05 PST (The first two are RFC822 format, which, interestingly, RFC882 violates in its own examples section -- there, it uses something like the last one, except with no `:' between hours/minutes. No one has ever complained about encountering that format.) --- * day_number month_name year_number time-timezone (day) * ^no colon separator 5 Feb 1990 140557-PST (Mon) 5 Feb 1990 1405-PST (Mon) 5 Feb 1990 1405-0800 (Mon) [??] (Does this ever show up with a GMT-offset as zone? Does it ALWAYS show up with a GMT-offset, and the "-" is part of the time rather than a separator?) === This next format is a bit suspicious. I wonder if that "-" floating out there is the beginning of a GMT-offset zone. Anybody know? --- * day_number month_name year_number, time "-" 5 Feb 1990, 14:05:57 - 5 Feb 1990, 14:05:57 -0800 [??] === These formats are not known to have time zones. Recognize any of them? --- * day_name month_name day_number time year_number Mon Feb 5 14:05:57 1990 --- * day_name month_name day_number year_number time Mon Feb 5 1990 14:05:57 --- * day_number month_name year_number 12_hour_time am_or_pm Mon Feb 5 1990 02:05:57 pm --- * day_name day_number month_name year_number time Mon 5 Feb 1990 14:05:57 --- * day_number month_name year_number time 5 Feb 1990 14:05:57 --- * day_number-month_name-year time 5-Feb-1990 14:05:57 --- * day_name, day_number-month_name-year time Mon, 5-Feb-1990 14:05:57 === Any help you can send along is appreciated, but please don't bombard me with mail unless you have some idea what you're talking about, or can show me an example of one of the time-zone-less formats above showing where the timezone can be found. Thanks! -- Bart Schaefer "February. The hangnail on the big toe of the year." -- Duffy schaefer@cse.ogi.edu (used to be cse.ogc.edu)
kjones@talos.uu.net (Kyle Jones) (02/13/90)
Barton E. Schaefer writes: > * day_number month_name year_number time timezone ... > > 5 Feb 1990 14:05:57 PST > 5 Feb 1990 14:05:57 -0800 > 5 Feb 1990 14:05 PST > (The first two are RFC822 format, which, interestingly, RFC882 > violates in its own examples section -- there, it uses something > like the last one, except with no `:' between hours/minutes. No > one has ever complained about encountering that format.) None of these are RFC 822 complaint because the year number is supposed to only have two digits. I think you're working too hard with these date formats. At some point you've got to blow off all these nonstandard variants and just stick with the standard. You're going to be old and gray with all but six marbles gone before you manage to grok all the wierd date formats out there. I suggest that you handle two: RFC 822 and the format the UNIX date(1) command returns.
schaefer@ogicse.ogc.edu (Barton E. Schaefer) (02/13/90)
In article <1990Feb12.181547.27427@talos.uu.net> kyle@xanth.cs.odu.edu writes: } Barton E. Schaefer writes: } > * day_number month_name year_number time timezone ... } > } > 5 Feb 1990 14:05:57 PST } > 5 Feb 1990 14:05:57 -0800 } > 5 Feb 1990 14:05 PST } } None of these are RFC 822 complaint because the year number is supposed } to only have two digits. Typo, my apologies. You'll find that mush actually does use only 2 digits whenever it creates such a date. It will, however, accept either 2 or 4 digits when parsing it, which is part of the reason I mistyped here. } I think you're working too hard with these date formats. At some point } you've got to blow off all these nonstandard variants and just stick with the } standard. You're going to be old and gray with all but six marbles gone } before you manage to grok all the wierd date formats out there. Undoubtedly, but I think we should at least try to do a better job with the several that we already grok. -- Bart Schaefer "February. The hangnail on the big toe of the year." -- Duffy schaefer@cse.ogi.edu (used to be cse.ogc.edu)
steve@thelake.mn.org (Steve Yelvington) (02/13/90)
[In article <1990Feb12.181547.27427@talos.uu.net>,
kjones@talos.uu.net (Kyle Jones) writes ... ]
> Barton E. Schaefer writes:
> > * day_number month_name year_number time timezone ...
> >
> > 5 Feb 1990 14:05:57 PST
> > 5 Feb 1990 14:05:57 -0800
> > 5 Feb 1990 14:05 PST
> > (The first two are RFC822 format, which, interestingly, RFC882
> > violates in its own examples section -- there, it uses something
> > like the last one, except with no `:' between hours/minutes. No
> > one has ever complained about encountering that format.)
>
> None of these are RFC 822 complaint because the year number is supposed
> to only have two digits.
That is no longer true; see the following excerpt:
RFC1123 MAIL -- SMTP & RFC-822 October 1989
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.
(Followups are directed to comp.mail.headers.)
--
Steve Yelvington at the (thin ice today) lake in Minnesota