Subject: RE: [ietf-dkim] Format for t=

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 20 Apr 2006 20:57:20 -0700

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-masked] 
> [mailto:[email-masked]] 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-masked]
> 
> 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
> 
> 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Apr 2006 05:51:34 -0700

>Empirically the programers cannot handle human friendly time. 
Well, that was pretty much my motivation to Sf70. A close runner up was
Kingon Kliques. But human readable stuff makes my hurt if I actually want
to perform some operation on it. If there isn't some posix-y like thing 
to do
it for me, I shudder in fear. Luckily Sf70 has all of those in spades.

       Mike