Subject: PaceDates

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 09:49:53 +0200

I've hacked the PaceDates a bit to accommodate the needs I have seen for  
dates in Atom, but also to cater for the existing practice. Alas, this  
leaves us with a pretty big bag of dates, but that won't be a problem if  
all of them are well specified, and if current practice is captured with  
at least one of the date constructs proposed:

<url: http://intertwingly.net/wiki/pie/PaceDates>

== Proposal ==

Replace or append to section 3.3, 4.13.6, 4.13.7 and 4.13.8 the following:

=== 3.3 Date Constructs ===

A Date Construct is an element whose child content is an RFC 3339  
Date-Time string [RFC 3339] which SHOULD be less than or equal to the  
variable "now". That means that a Date Construct SHOULD NOT contain a date  
in the future.

If a Date Construct does not exist, it MUST NOT be assumed to have the  
semantic or value of any other Date Construct.

=== 4.13.6 "atom:modified" Element ===

The "atom:modified" element is a Date Construct that indicates the time  
that the entry was last modified. atom:entry elements SHOULD contain an  
atom:modified element, but MUST NOT contain more than one. If no other  
Date Construct is available for the atom:entry, atom:modified MUST be  
present.

The content of an atom:modified element MUST according to RFC 3339 have a  
time zone whose value SHOULD be "+00:00" or "Z".

If an atom:entry is re-issued at several different locations,  
atom:modified MAY be altered to indicate this change in the entry's state.

An atom:modified date does only give a slight indication of modification.  
If atom:modified has not changed, it is safe to assume that the entry  
itself has not changed either. However, a change in atom:modified does not  
necessarily imply a change in the entry itself.

=== 4.13.7 "atom:issued" Element ===

The "atom:issued" element is a Date Construct, giving the date of formal  
issuance (e.g., publication) of the entry. atom:entry elements SHOULD  
contain an atom:issued element, but MUST NOT contain more than one. If no  
other Date Construct is available for the atom:entry, atom:issued MUST be  
present.

The content of an atom:issued element MUST according to RFC 3339 have a  
time zone whose value SHOULD be "+00:00" or "Z".

If an atom:entry is re-issued at several different locations, atom:issued  
MAY be altered to indicate this change in the entry's state.

=== 4.13.8 "atom:first-issued" Element ===

The "atom:first-issued" element is a Date Construct, giving the first date  
of formal issuance (e.g., publication) of the entry. atom:entry elements  
SHOULD contain an atom:first-issued element, but MUST NOT contain more  
than one. If no other Date Construct is available for the atom:entry,  
atom:first-issued MUST be present.

The content of an atom:issued element MUST according to RFC 3339 have a  
time zone whose value SHOULD be "+00:00" or "Z".

If an atom:entry is re-issued at several different locations, atom:first  
MUST NOT be altered to indicate this change in the entry's state.

=== 4.13.9 "atom:created" Element ===

The "atom:created" element is a Date construct that indicates the time  
that the entry was created. atom:entry elements SHOULD contain an  
atom:created element, but MUST NOT contain more than one. If no other Date  
Construct is available for the atom:entry, atom:created MUST be present.

The content of an atom:modified element MUST according to RFC 3339 have a  
time zone whose value SHOULD be "+00:00" or "Z".

=== 4.13.10 "atom:date" Element ===

The "atom:date" element is a Date Construct, giving the date associated  
with the entry. Typically, atom:date will be associated with the creation  
or availability of the resource, but its semantics is laregely up to the  
tools to define. atom:date exists for compatibility reasons and therefore  
SHOULD NOT be used. atom:entry elements MAY contain an atom:date element,  
but MUST NOT contain more than one. If no other Date Construct is  
available for the atom:entry, atom:date MUST be present.

The content of an atom:date element MUST according to RFC 3339 have a time  
zone whose value SHOULD be "+00:00" or "Z". The time zone MAY, however, be  
"-00:00" when the time is known to be correct UTC, but the time zone is  
unknown, or be '+hh:mm' when the time zone is known.

atom:date MAY change to order the entries in an Atom feed or on a front  
page of a website correctly. It MAY also change to convey the date the  
author wants associated with the entry.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: David Powell <[email-masked]>
Date: Thu, 29 Jul 2004 22:10:02 +0100

[Sorry if you get this twice. I sent it a few hours ago but it seems
to have gone missing]

This looks like a very good compromise. I agree with everything but
I have a few minor issues with a few of the SHOULDs and SHOULD NOTs
related to atom:date...

> Date-Time string [RFC 3339] which SHOULD be less than or equal to
> the variable "now". That means that a Date Construct SHOULD NOT
> contain a date in the future.

I realize that this is only a SHOULD, but I think that there are
sensible reasons for allowing atom:date to be in the future. How about
a feed of upcoming events, or weather forecasts (such as these
concrete examples [1])? I don't think that this recommendation
improves interoperability, so I don't think that we need to recommend
it.

> The "atom:date" element is a Date Construct, giving the date
> associated with the entry. Typically, atom:date will be associated
> with the creation or availability of the resource, but its semantics
> is largely up to the tools to define. atom:date exists for
> compatibility reasons and therefore SHOULD NOT be used.

This is not how I see atom:date at all. I see it as a piece of
metadata that a publisher wants to associate with the content of the
entry, rather than a date associated with the publishing process like
the other dates are. I see it as a useful field that is present for
more reasons that backwards compatibility.

-1 to the SHOULD NOT.

Also I don't like the use of the word "tools" in that paragraph, I'd
prefer "publisher". This is a field that allows the user to associate
a date with an entry if they want to. I don't think that tools should
generate it, other than perhaps to propose Now() as a default.

> The content of an atom:date element MUST according to RFC 3339 have
> a time zone whose value SHOULD be "+00:00" or "Z".

I disagree with the SHOULD. In fact I think that this date is more
useful if it includes the timezone of the publisher, but I'd prefer it
if we stayed silent and not recommend either option. It is up to the
publisher.

> atom:date MAY change to order the entries in an Atom feed or on a
> front page of a website correctly.

This implies that atom:date should be used to indicate the sort order,
but I'd rather we didn't say anything about that - it is up to the
User-Agent to decide on a sort order. So, I'd rather just drop that
sentence.

I'd prefer the atom:date section to look something more like this:

  The "atom:date" element is a Date Construct, giving the date
  associated with the entry. Typically, atom:date will be associated
  with the creation or availability of the resource, but its semantics
  is largely up to the publisher to define. atom:entry elements MAY
  contain an atom:date element, but MUST NOT contain more than one. If
  no other Date Construct is available for the atom:entry, atom:date
  MUST be present.
  
  The content of an atom:date element MUST according to RFC 3339 have
  a time zone. The time zone may be "+00:00" or "Z" to represent UTC;
  a local offset when the time zone is known; or "-00:00" when the
  time is known to be correct UTC, but the time zone is unknown.
  
  atom:date MAY change to convey the date the author wants associated
  with the entry.

It would be good to get Tim's travel journal example in the document
somewhere because that explains it pretty well.

[1]  http://www.anti-mega.com/weather/

-- 
Dave

---

From: Antone Roundy <[email-masked]>
Date: Thu, 29 Jul 2004 15:47:42 -0600

> more reasons that backwards compatibility.
[snip]
>   is largely up to the publisher to define.

I think the distinction between atom:date and other dates as we've both 
expressed it just now it a good start for spec text.  For example:

'The "atom:date" element is a Date Construct giving a date associated 
with the contents of the entry, which might not be related to events in 
the publishing process...'

We don't want to state that it ISN'T related to events in the 
publishing process, because often it will be, or at least it will 
coincide with those dates.  But saying "might not be related..." 
uncouples the meaning of this date from the publishing process.

On Thursday, July 29, 2004, at 03:15  PM, Asbjørn Ulsberg wrote:
> On Thu, 29 Jul 2004 19:27:36 +0100, David Powell 
> <[email-masked]> wrote:
>> I realise that this is only a SHOULD, but I think that there are 
>> sensible reasons for allowing atom:date to be in the future.
>
> I think the consensus is that it's not.
Disagreed.  I haven't noticed much general opposition to future 
subjective dates.  But maybe I just haven't been listening.

>> How about a feed of upcomming events, or weather forecasts
>
> If these are compelling use cases Atom needs to support, we should 
> embrace Dublin Core's 'available'[1] date that I think should cover 
> these use cases pretty well.
Disagreed again.  A weather forecast for next week is made "available" 
before next week.  Next week's date seems appropriate for atom:date in 
these kinds of cases.  This might be a different usage from how date 
fields in existing formats and blogging tools are used, but given that 
we're providing separate places for dates related to the publishing 
process, it feels like the right thing to do with this element.

>> I see it as a useful field that is present for more reasons that 
>> backwards
>> compatibility.
> atom:date exists purely to cater for the date the current publishing 
> tools provide for their entries. Please see BlogToolDateSurvey[2] for 
> details.
>> This is a place that allows the user to associate a date with an entry
>> if they want to.
> Some tools do this, others don't.
Perhaps your conception of atom:date is as nothing but a dumping ground 
for bad data when no better data exists, but there are other potential 
uses for subjective dates, as has been pointed out here and in previous 
discussion.  I for one don't have a problem with it being used both for 
user-selected dates and for sticking whatever date is available when 
all the more tightly specified dates are unknown.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 30 Jul 2004 11:55:41 +1000

> uncouples the meaning of this date from the publishing process.

+1

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 30 Jul 2004 08:37:54 +0200

> the publishing process...'

+1 and thus implemented.

> subjective dates.  But maybe I just haven't been listening.

Okay. I've changed the pace accordingly, to discourage future dates in the  
formal publishing-process related dates, but allow for it in atom:date.

> these kinds of cases.

Yes, that's probably correct.

> for bad data when no better data exists

Partly, yes. The reason for this is that there is no way to sum up the  
current date usage with one term or one conception. There is absolutely no  
shared semantics between the tools on what the date actually is, and  
that's why atom:date use should be discouraged, and tools should move over  
to the more semantically meaningful ones.

> but there are other potential uses for subjective dates, as has been
> pointed out here and in previous  discussion.

Yes, atom:date may of course be used as a subjective date element, but how  
do we capture that essence in the specification text and still support  
non-subjective dates as a means to cater for current usage? The date can  
today be both subjective and objective. Can we somehow state that  
atom:date SHOULD NOT be objective or tool-specified, and that objective  
dates should share the semantics of 'issued', 'modified' or 'created' and  
thus use those elements instead?

> I for one don't have a problem with it being used both for user-
> selected dates and for sticking whatever date is available when

I agree, but as the current situation is so chaotic, I'm not sure how to  
solve this specification-wise.

---

From: Walter Underwood <[email-masked]>
Date: Fri, 30 Jul 2004 10:27:39 -0700

--On Friday, July 30, 2004 8:37 AM +0200 Asbjørn Ulsberg <[email-masked]> wrote:
> Okay. I've changed the pace accordingly, to discourage future dates in
> the  formal publishing-process related dates, but allow for it in atom:date.

We cannot talk about future dates without choosing a reference
clock. Server or client? HTTP header dates? An NTP stratum 1 clock?

NNTP got this wrong, using a client date to select server-dated
items, so articles are consistently missed or double-fetched,
depending on the sign of the clock skew.

Without a reference clock, "there's no future, we mean it, man".

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 30 Jul 2004 23:21:54 +0200

On Fri, 30 Jul 2004 10:27:39 -0700, Walter Underwood <[email-masked]>  
wrote:

> clock.

Good point. «Future date» should be UTC-normalized and compared with the  
current UTC datetime, on the server.

> depending on the sign of the clock skew.

Yes. Clients are very unreliable. Every now and then, someone on USENET  
gets thoroughly spanked because they've misconfigured their date in the  
operating system. User's screwups should as far as possible not influence  
the reliability of the information provided in the format or protocol.