Date: Wed, 27 Mar 96 12:23:22 +0100
Message-Id: <9603271123.AA02995@othello.admin.kth.se>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Olle Jarnefors <ojarnef@admin.kth.se>
To: drums@cs.utk.edu
Cc: Olle Jarnefors <ojarnef@admin.kth.se>
In-Reply-To: <827871857.1525.0@nifty.andrew.cmu.edu> (Tue, 26 Mar 1996 15:24:17 -0500 (EST); From: Chris Newman <chrisn+@CMU.EDU>)
References: <199603261929.OAA17321@CS.UTK.EDU> <827871857.1525.0@nifty.andrew.cmu.edu>
Subject: Re: timezones & Date

Here are my ideas about the Date problems:

1) If the MUA/MSA knows the actual time but not the user's local
   time or time zone, it should use the time zone indication
   "-0000" instead of "+0000", to announce that this time is
   correct but may not reflect the user's local time. (I checked
   7809 recent messages and found 330 with "+0000" and 0 with
   "-0000".) There are by the way situations in which the local
   time zone is ill-defined, e.g.  on board an airplane crossing
   the Atlantic.

2) What if the MUA/MSA knows the local time but not the time
   zone or the actual time? It should ask the user about the
   time zone (and save the answer for future use). The user
   should be given a clear option to answer "Don't know".
   
   a) If he lives in a country with several time zones like USA
      it's very likely that he can give an answer, at least by
      choosing from a list with acronyms and descriptions of
      time zones in these countries.
   
   b) If the user ansers "Don't know", the MUA/MSA can use the
      top-level domain of its own address (which is a national
      2-letter domain in most of these cases) and the local time
      to determine the normal time zone with good accuracy and
      any daylight saving time correction with good accuracy
      most of the year. At least the deviation from the true
      actual time shouldn't be bigger than one hour. (The normal
      time zone of a country is very unlikely to change, so it
      is sufficient for the MUA/MSA to have a static table
      giving country code, normal time zone offset and a
      daylight saving time indicator: not used, used at the
      middle of the year, used at new year.)

3) If the MUA/MSA doesn't know either the actual time or the
   local time, it will have to ask the user about the local
   time. This case is then reduced to case 2.

In case 2 there is of course a non-zero probability that an
incorrect Date field is included in the message. I suggest that
this uncertainty should be indicated in the Date field
by a "(?)" comment. The difference between the time given and
the actual time shouldn't be more than 25 hours in the worst case
anyway, so the Date field still gives plenty of useful time
information. The risk of an error as small as this is not
sufficient reason in my opinion for the MUA/MSA to refuse
sending the message.

I'm uncertain about how much on the implementation options that
needs to be included in 822bis. Maybe it would be best to only
specify the special semantics of "-0000" (don't trust the local
time) and the comment "(?)" (actual time somewhat uncertain,
worst case deviation 25 hours). And of course strong language
about the importance of including correct Date information,
especially about the actual time.

-- 
Olle Jarnefors, Royal Institute of Technology (KTH) <ojarnef@admin.kth.se>