Subject: Date accuracy

From: Graham <[email-masked]>
Date: Fri, 25 Mar 2005 13:47:29 +0000

There are several RSS feeds out there that have dates where the day is 
accurate but the time is always the same (usually 10am for some 
reason), regardless of the time of publication, which completely messes 
up sorting the day's entries. Currently the Atom spec implies that this 
is bad practice by requiring a time, but could we make it explicit?

Proposal: Add to Date Construct section:
"Date values must have a granularity of one second"

Graham Parks

---

From: Tim Bray <[email-masked]>
Date: Fri, 25 Mar 2005 09:01:59 -0800

> "Date values must have a granularity of one second"

Could we make this a SHOULD?  Whereas Graham is correct in the normal 
case, I have an alternate scenario at 'ongoing'.  Normally, the 
"updated" comes from the timestamp on the input version of the file; I 
don't have any externally-stored datestamps aside from knowing the day 
it was created.  However, when I don't want to show the thing as 
updated, I put a special <finished/> element in the input version and 
the software then emits a pubDate of 02:00 hours on the creation day.  
This works well enough, but if it were a MUST, I'd have to keep one 
more date value around for each piece, which seems to have a lousy 
return on investment. -Tim

---

From: Graham <[email-masked]>
Date: Fri, 25 Mar 2005 17:52:54 +0000

On 25 Mar 2005, at 5:01 pm, Tim Bray wrote:

> Could we make this a SHOULD?

Yes, I agree SHOULD is the appropriate RFC term.

Graham

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 25 Mar 2005 13:07:08 -0500

> "Date values must have a granularity of one second"

The current format of the date has a granularity of one second.

Are you requesting that dates SHOULD be *accurate* to the second by
whatever process is generating the Atom document?

If that is correct, how does adding this restriction  increase interop?

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Walter Underwood <[email-masked]>
Date: Fri, 25 Mar 2005 10:46:59 -0800

--On March 25, 2005 1:47:29 PM +0000 Graham <[email-masked]> wrote:
> 
> There are several RSS feeds out there that have dates where the day is accurate
> but the time is always the same (usually 10am for some reason), regardless of
> the time of publication, ...

> "Date values must have a granularity of one second"

Precision and accuracy are very different things. Precise timestamps
have a lot of numbers. Accurate timestamps are a correct measurement
of a clock.

Does this mean that they must have an accuracy of one second? That is, that
the timestamp for the update or publish event must be correct within +/- 0.5s 
when compared to a trusted time standard?

Atom already requires the timestamp to be precise to one second, but it is not
practical to require (MUST) accuracy. We could do it, but we'd lock out the 99%
of machines with bad clocks.

Plus, some publications just don't have an accurate time -- archives digitized from
paper, like old New Yorker issues or MIT AI lab tech notes. One approach to those
is to choose a convention for the time portion, like noon UTC. That is 
most likely to be the same day in other time zones. We could mention that as
a useful convention.

The Atom spec should recommend that clocks be accurate. There is no point in
having sortable timestamps without trustworthy clocks. This is already a
SHOULD in the HTTP 1.1 spec, and you can grab that language from the 
caching Pace I put together. Or I can, if there is support for it.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Tim Bray <[email-masked]>
Date: Fri, 25 Mar 2005 11:17:16 -0800

On Mar 25, 2005, at 10:46 AM, Walter Underwood wrote:

> paper, like old New Yorker issues

First, I don't think that we currently require any precision, we just 
specify the syntax, which happens to allow to-the-second precision.  
Graham's point is that the spec should acknowledge that there is value 
in accuracy, which is well-taken.  I suggest language such as:

  The date SHOULD be as accurate as possible within the
  limitations of the software and environment.  For example, it would
  be generally inappropriate for a publishing system to apply the same
  timestamp for several entries which were published during the course
  of a single day.

On the other hand, this amounts to telling publishers "don't be 
egregiously stupid"... not obvious that you get an interoperability 
gain.  Except for Graham says he's seeing people doing just this. -Tim