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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 > [EMAIL PROTECTED] > > 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
