I don't like seconds from 1970 but I like RFC 3339 even less.
Seconds since 1970 is unambiguously UTC. RFC 3339 means well but there is no
practical way to insist on UTC and no practical way to ensure that
developers encode local time reliably.
With seconds since 1970 all I have to worry about is whether the machine is
set up correctly which these days is usually the case.
What is utterly bizare is the failure of virtually every callendaring scheme
to work reliably due to the insistence of the dufus programmers of coding
into local time then getting it wrong. You would think someone writing an
application that has the job of reading an air travel itinerary and
installing it in a calendar would figure out the need to adjust for local
time but no...
Empirically the programers cannot handle human friendly time.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Tony Hansen
Sent: Thursday, April 20, 2006 9:41 PM
To: IETF-DKIM
Subject: Re: [ietf-dkim] Format for t=
*If* we're going to switch away from "seconds from 1970", we
should use the standardized time format described in RFC
3339: Date and Time on the
Internet: Timestamps. IMHO, using anything else would be
irresponsible.
However, I don't think we have to switch.
Tony Hansen
tony(_at_)att(_dot_)com
Douglas Otis wrote:
On Apr 20, 2006, at 3:55 PM, Michael Thomas wrote:
Jim Fenton wrote:
I'm not sure I want to start another discussion about the
"t=" tag
like we had about the "x=" tag, but I'm even less sure
what to do with t=.
Do we want to base the format on that of t=?
Do statistics and forensics count for nothing these days?
From a prior conversation, I think the concern was whether to use
seconds from 1970 or the RFC2822 date time format.
Standardizing on a
consistent format with that of the other headers being
examined would
also permit a recipient to understand what the time stamp value
represents. The conversion routines are already be available.
The draft could recommend encompassing an evaluated Date
header within
the signature, or providing for a human readable t= time stamp when
the Date header differs significantly.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html