On Sat, 21 Dec 1996 16:03:26 GMT Daniel Norton <[log in to unmask]> said:
 
>Let me  get this straight: LISTSERV  works by validating the  date field
>but ignores  processing the time  zone; SunOS inews validates  the whole
>field and is broken?? GMAB.
 
LISTSERV  validates the  "Date:"  field,  allowing any  time  zone to  be
specified, for the reasons that  I have explained. Under no circumstances
will LISTSERV reject a message due to  a bad "Date:" field. If the syntax
is mildly  incorrect (no  weekday, '96'  instead of  '1996', etc),  it is
repaired, otherwise a new "Date:" field is generated.
 
SunOS validates the whole date and rejects messages with an invalid date,
thus  losing valuable  information which  a human  could have  understood
perfectly well. I call this broken.  I don't know if SunOS validates only
the numeric form or all forms,  but if it also validates the three-letter
forms it is bound to throw away  a lot of mail from non-US sources, which
I also call broken.
 
As I see it, RFC822 created a big mess with the time zone issue. The only
reasonable solution  is to (1) encourage  people to use the  numeric form
(which has been done) and (2) categorize date fields as follows:
 
a. Fields which have a valid numeric time zone. The time zone can be used
   for whatever processing may be desired.
 
b. Optionally,  fields which have one  of a number of  well defined three
   letter time  zones (EST,  PST, etc),  for which  no usage  conflict is
   known. These can be used as above.
 
c. Other date  fields. The time zone information is  meaningful only to a
   human  reader and  the program  should assume  that no  time zone  was
   specified.
 
Any program which ignores the factual existence  of c is a program that I
call broken.  On top of  this, there is the  fact that many  mail readers
don't know their time zone. Pegasus for instance seems to always give you
GMT. That's one reason I personally never try to use time zones for much.
 
  Eric