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. 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).
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.
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.
hence the SHOULD
<shrug /> It's no important point, I wouldn't miss it if you
drop the SHOULD.
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.
Frank