Pete Resnick 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.
My example was a lunar base, but I think it's generally a good
idea.
I'm 100% behind Pete on this one - using UTC is usually a terrible idea (unless
of course your local time zone happens to be UTC) bcause it causes important
information to be lost.
Looking at say IETF WG meeting times I often have no
clue what they mean in UTC (from where I could do the math for
my local time).
This is a completely different problem and irrelevant to the matter at hand -
if the proper time zone isn't clearly identified that's a bug in the
information published about the meeting, one which cannot occur in 2822bis
without violaating the specification.
I will also point out that the issues with future meeting times is one which in
general is NOT solvable by giving UTC times or any times with any specific
offset. This is the old zone offset versus zone rule issue: An IETF meeting is
going to be held at times curresponding to whatever zone offset is _in effect_
at the venue where the meeting is held. Suppose it is announced that next
year's meeting is being held in, oh, let's say Israel. But between then and now
the Knesset decides to change the applicable daylight savings time rules and
this causes the zone offset to change. Times published in _any_ fixed offset
will now be incorrect. (I chose Israel for this example because it's a place
that piddles with these things more often than most.)
For Date header fields it's not as bad, at least there is an
offset, I have only to get the sign magic right for UTC, and
from UTC it's again easy.
Exactly - there's no real upside, and a considerable downside, to using UTC.
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.
For readers in a completely different time zone it's a matter
of taste. Likely I'm biased because I live near to UTC. But
UTC has no DST, a huge advantage.
Only in the sense that it makes things a tiny bit easier to implement on some
systems. If the system clock is run in UTC then of course it is easier to stuff
in a UTC time value. But unless he system can't add or substract properly, the
worst that can happen in converting to local time is that the wrong offset to
UTC is chosen and the point in time is identified correctly but the offset is
wrong.
And not all systems run their clocks in UTC. (In fact the machine I'm using
right now to enter this message uses a local time clock.) Such systems are at a
disadvantage because if they don't know the correct offset they cannot get the
right point in time into the header. However, if such systems are forced to
convert to UTC and mess it up there's now no indication in the header of
problem because then there's no offset you can look at and say, "I know this
was sent from California and that's the wrong offset for California right now".
The bottom line is more information is almost always better.
hence the SHOULD
<shrug /> It's no important point, I wouldn't miss it if you
drop the SHOULD.
I would strongly object to this SHOULD being removed.
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."
+1
[2718]
It's semantically valid, whether or not it is currently used.
There is no good reason to disallow such a value.
99 hours is rather obscure, four days aren't enough for an
attempt to live in "local Julian time". You could limit it
to say 23 hours. With that the syntax would more obviously
indicate that it's actually about hh:mm and not 9999 minutes.
Again I'm with Pete - I see no reason for such a restriction.
Ned