SCOUG-HELP Mailing List Archives
Return to [ 08 | 
October | 
2003 ]
<< Previous Message << 
 >> Next Message >>
 
 
 
Content Type:   text/plain 
=====================================================  
If you are responding to someone asking for help who  
may not be a member of this list, be sure to use the  
REPLY TO ALL feature of your email program.  
=====================================================  
 
Quick important note:  See the bottom half of this message -- the SCOUG  
list server appears to be in violation of proper time zone  
identification on the Date line.  
_____  
 
Steven Levine wrote:  
>   
> Here's an outbound [timetest msg] send at 5:50pm PDT.  
 
Steven,  
 
All three test messages arrived here with the proper time displayed  
(17:39, 17:48, 17:49) in my Netscape 2.02 email client, but:  
 
-- 1) the first two headers show +0000 for the X-OldDate while the third  
header shows -0700  
 
-- 2) the X-OldDate differential is 8 hours, not 7 hours as it should be  
(take a look at the headers if you didn't already notice this latter  
problem).  
 
Curiosity questions about your three test messages:  
 
-- Why is the Date (X-OldDate after restamping) in your third test  
message shown as -0700 while the first two are +0000?  
 
-- Did the settings you used for the first two test messages cause  
Mozilla to convert those outbound header Date stamps to GMT?    
 
It doesn't look like you were changing the TZ value because the message  
time was *adjusted* to +0000 rather than just labeled as +0000 (and note  
again that the adjustment was an incorrect 8 hours rather than the  
appropriate 7 hours).  
_____  
 
    TIME ZONE ABBREVIATIONS NOW OBSOLETE AS PER RFC 2822  
 
Finally, is it possible that Mozilla doesn't understand "PDT7" which the  
SCOUG list server uses in the restamp?  If you (or Ray) manually change  
the message from "PDT7" to "-0700" does the correct time miraculously  
appear?  A few years ago I ran into this particular problem where an  
abbreviation used for the time offset wasn't understood by all software.  
 
IMPORTANT:  "PDT7" isn't supported by RFC 2822 "Internet Message Format"  
(email format and the revision of RFC 822) -- see section 3.3 and also  
section 4.3 which explicitly states that time zone abbreviations (such  
as "PDT") are obsolete (i.e. the SCOUG list server is in violation of  
RFC 2822).  ("PDT" was allowed in the earlier RFC 822 -- see section  
5.1.)  
 
Also see RFC 2821 "Simple Mail Transfer Protocol" section 4.4 which says  
in reference to Received (not Date) fields:  
 
    "SMTP servers that create Received fields SHOULD use  
    explicit offsets in the dates (e.g., -0800), rather  
    than time zone names of any type.  Local time (with  
    an offset) is preferred to UT when feasible."  
 
and it is possible that the same applies to Date lines although I can't  
find a reference in RFC 2821 for the Date line format.  
 
Thus, Mozilla may be following _only_ RFC 2822 and ignoring the time  
zone abbreviations which were allowed in the earlier RFC 822.  A quick  
manual change of a message header from -0700 to PDT7 and vice versa  
should discern Mozilla's acceptance of the "PDT" abbreviation.  
 
RFC 2821 is dated April 2001 whereas RFC 822 is dated 1982.  
 
- Peter  
 
 
=====================================================  
 
To unsubscribe from this list, send an email message  
to "steward@scoug.com". In the body of the message,  
put the command "unsubscribe scoug-help".  
 
For problems, contact the list owner at  
"rollin@scoug.com".  
 
=====================================================  
 
  
<< Previous Message << 
 >> Next Message >>
Return to [ 08 | 
October | 
2003 ] 
  
  
The Southern California OS/2 User Group
 P.O. Box 26904
 Santa Ana, CA  92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group.  ALL RIGHTS 
RESERVED. 
 
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International 
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
 
 |