🚀 go-pugleaf

Excerpts from netnews.comp.mail.misc: 17-Oct-90 Re: timezone names Dan
Heller@turnpike.Eng. (1517)

> Actually, it's AEST, not EST.  But the standards say that timezones
> *outside* of the US must use numeric representations, not  the ascii
> versions.  Conversely, Mail *in* the US must use the 3-letter ascii
> abbreviations.

Nope--all mail may (and should) use numeric zones.  RFC 822 allows
numeric or military zones anywhere.   RFC 1123 says the following (on
page 55):

         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.

Excerpts from netnews.comp.mail.misc: 17-Oct-90 Re: timezone names Dan
Heller@turnpike.Eng. (1517)

> > Down with TLAs, let's go numeric.
> let's go with standards...
> But the -real- solution is to allow the MTA to supply the Date: header.

> > Grumble. Yet another reason to prefer MH.
> MH has nothing to do with this.  In fact, if MH is adding a Date: header,
> it's yet another reason *not* to use MH.  Mush provides a date header
> by default because there are many non-rfc compliant MTAs out there that
> people are using and Mush has to work with them.  You can (and should)
> configure this out before building Mush if you use 822-complaint MTAs.

The RFCs say nothing about whether the user-agent program or the MTA
program  should provide a Date: header; they say only that the mail must
have a Date: header by the time it leaves your MTA bound for another
one.  Sendmail set the precedent (NOT the ``standard'') that the MTA
should provide the Date: header, but I think it's foolish to do it that
way.

This message left Transarc with a Date: header with a numeric time zone
spec.  I'm prepared to argue RFCs with all comers on that point.  I have
no idea where the impression came from that numeric zone IDs are not
permitted to describe North American time zones.

Let's not confuse fact with impression.

		Craig