[Top] [All Lists]

Re: 2822upd-04 "local" time and zone offsets

2008-01-27 22:44:55

On 1/27/08 at 8:23 PM -0500, Bruce Lilly wrote:

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

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".

Using UTC is a terrible idea. The entire idea of the "Date:" field is to allow the author to convey the time at which the message was created. It is often important information to the author (and to the reader) what local time the message was created. ("Was this written in the morning or the evening for the author?") There *are* valid reasons not to use local time (when you want to hide the information for some reason, or when you cannot reliably calculate it), hence the SHOULD, but implement the spec in such a way that you always use UTC creates information loss to the author and reader, and "the full implications must be understood".

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.

The above are not security implications; they are reasons people sometimes get local time wrong. Programming is sometimes hard.

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:

That's not a security implication; that's a legal implication.

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)?

Yeah, someone else mentioned this to me. I've changed it to:

"and the last two digits of zone MUST be within the range 00 through 59."

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's semantically valid, whether or not it is currently used. There is no good reason to disallow such a value.

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.

Using a "Bob" for the day-of-week, or "31 Feb", or "75:75:75" for the time-of day has the potential to really screw up code. I'm not clear on how having strange zone offsets does.

Pete Resnick <>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102