ietf-822
[Top] [All Lists]

2822upd-04 "local" time and zone offsets

2008-01-27 18:40:42

On Sunday 27 January 2008 11:18:37 Frank Ellermann wrote:

[regarding 2822upd-04 text
   The date and time-of-day SHOULD express local time.
] 

they can pick UTC.  Maybe 2822upd could drop the
SHOULD (?)

I'd like to see it dropped, or better still, replaced by a recommendation
to use UTC.  That would partially remove the need to define "local".

Regardless, there are security implications related to use of "local"
rather than UTC.  The issues arise from the difficulty in converting
*correctly* to an unambiguous time reference (i.e. UTC) which in turn
is partially due to an unfortunate choice in the sign of the offset,
(resulting in erroneously adding the offset to local time to get UTC
when it should be subtracted).  They also partially arise from the
"local" time issue of "Daylight Savings Time" (or equivalent by any
other name) and the horrendously complicated rules (which vary from year
to year and place to place) for additional offsets.

I recall one instance where a person was wrongly accused because his ISP
made the offset conversion incorrectly (unfortunately I cannot now find
a reference), and here is a link to a case (not mail-related) of the DST
issue, also resulting in wrongful accusation:
http://yro.slashdot.org/article.pl?sid=07/04/17/1240237

These security considerations should be mentioned in the draft.

Aside from those issues, there are ambiguities in the 2822upd-04 text:

    and the zone MUST be
   within the range -9959 through +9959.

Is +2586 legal (it IS within the numeric range -9959 through +9959)?

What about semantics; what does +2718 mean (there are no actual time
zones outside the range -1200 to +1400, and none whose offset is not a
multiple of precisely 15 minutes [*])?

It seems highly inconsistent that the 2822upd-04 text is so pedantic
about semantic validity of day-of-week, day-of-month, and time-of-day,
yet so lax about semantic validity of zone offsets.


* in fact there are none whose last two digits in 2822 notation would be 15,
  only 00, 30, and 45. Since the date field was first defined in RFC 561
  (September 1973) there have been no time zones whose offset from UTC is
  not a multiple of 5 minutes.  The last zone whose offset was not a
  multiple of 5 minutes was Liberia which went out of effect on May 1, 1972;
  prior to that date the Liberian offset was -44 minutes and 30 seconds
  (which cannot be represented with 2822upd-04 zone offsets as there is no
  provision for seconds). The last zone which was not a multiple of 15
  minutes offset from UTC was Kiritimati (-1040) and which went out of
  effect in 1979 (predating RFC 822, Pete).  See the latest version of the
  tzdata* file on
  ftp://elsie.nci.nih.gov/pub for all of the gory time zone offset details.