Subject: MUST be UTC?

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 08:17:51 -0400

On the subject of time zones, is it really necessary to use UTC? How is
"2004-07-08T07:11:53-04:00" really worse than "2004-07-08T11:11:53Z"?
I can understand not using forms like "2004-07-08T07:11:53EDT" but I'd
like the freedom to use the numeric forms.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | If you want to make an apple pie from
http://nwalsh.com/            | scratch, you must first create the
                              | universe.--Carl Sagan

---

From: Antone Roundy <[email-masked]>
Date: Sat, 10 Jul 2004 08:05:06 -0600

> like the freedom to use the numeric forms.

+1 to both allowing other timezones and requiring non-Z timezones to be 
numeric.

---

From: David Powell <[email-masked]>
Date: Sat, 10 Jul 2004 20:25:43 +0100

> like the freedom to use the numeric forms.

When you convert a date to UTC you are throwing information away.  It
is no longer possible to convert this back to the publishers local
time.  I assume that the reason for wanting to do this is if this
field is purely for machine/administrative use, and is not normally
displayed to a user.  Saying that the date MUST be in UTC makes it
a lot easier to sort feeds, produce aggregated feeds using XSLT, and
synchronize entries between feeds, because you can just do a string
sort.

If you want to display dates to a user then it is better to store them
in the publisher's local time with a timezone offset. This lets you
keep the time in the publishers local time if you want.

To me the current model seems to assume that atom:created and
atom:modified are for machine use, and that is why UTC is required.
Whereas atom:issued is for human display, and that is why local time
is preferred.

If atom:created and atom:modified are only for machine use, then
atom:issued starts to look a bit weak. If there can only be one
atom:issued, then tools will need to rely on atom:created and
atom:modified to find out about the entry's publishing history. But we
have already weakened these by throwing away their timezone offset...

I would prefer it if:

* There was exactly one atom:created and UTC was a MUST. This would be
the date that an entry was first created, and would not normally be
displayed.

* There was zero or one atom:modified and UTC was a MUST. This would be
the date that an entry was last changed, and would not normally be
displayed.

* There was an ordered list of atom:issued, and localtime + timezone
SHOULD be used. This would be the date that an entry was first posted
and the dates that the entry was updated, so it would be the human
displayable equivalent of the machine optimized atom:created and
atom:modified fields.

If atom:issued doesn't provide a timezone then no timezone should be
assumed. A lot of mobile clients don't know what timezone they are in,
it is wrong for the server to guess randomly, the server should just
display the time without a timezone. I don't see the need to perform
comparison operations on atom:issued - that is what atom:created and
atom:modified are for.

-- 
Dave

---

From: Antone Roundy <[email-masked]>
Date: Sat, 10 Jul 2004 15:04:52 -0600

On Saturday, July 10, 2004, at 01:25  PM, David Powell wrote:
> Saying that the date MUST be in UTC makes it
This is the first argument in favor of requiring (or encouraging) UTC 
that is at all convincing to me.  Still, I would prefer to be able to 
use my local timezone.  If some piece of software wants to have 
everything in the same timezone, it can do the conversion and store the 
data in it's preferred format.  Of course the timezone won't always 
correctly reflect where the author was, but I don't think that's enough 
reason to mandate always converting to UTC.

> Whereas atom:issued is for human display, and that is why local time
Good issues to consider, though I'm not sure I agree.  Let's nail these 
issues down when PaceEntryDates[1] comes up for discussion.  Once we 
know, and agree on, what each of the date elements really means, we'll 
have a basis for deciding requirements for each.

Antone

[1] http://www.intertwingly.net/wiki/pie/PaceEntryDates

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 01:01:04 +0200

> "2004-07-08T07:11:53-04:00" really worse than "2004-07-08T11:11:53Z"?

MSDN has a really good article that explains a lot of this, which is not  
only tied to the .NET framework:

<url:  
http://msdn.microsoft.com/library/en-us/dndotnet/html/datetimecode.asp>

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

---

From: "Bill Kearney" <[email-masked]>
Date: Sat, 10 Jul 2004 20:06:33 -0400

> time.

The timestamp is indeed the "same instant in time"  You're only throwing away
what "offset" was used to state the time.  But that value is likely to be wrong
in more than a few cases.  If my home base is on the East coast US and I post to
a server in France while on a plane over Tokyo, what time is it?  In UTC it's
one and only one time.  WHERE I was at that instant is a different issue.
Timezones ARE NOT GEO DATA.

> keep the time in the publishers local time if you want.

It does raise the question of how do you state "where", in a temporal sense, is
the data located?

> Whereas atom:issued is for human display, and that is why local time

The time will always have to be converted.  Going from local time EDT to UTC and
then to PDT  (-04:00, Z, -07:00) or from UTC directly to PDT.  That it came from
some guy in NYC at 6am "his time" might have some sort of mental relevance
(oooo, he's into work early today!) but it has little machine relevance.

> have already weakened these by throwing away their timezone offset...

Weakened HOW?  The time is the time is the time, same across all zones.

> displayable equivalent of the machine optimized atom:created and

Well, that might have some value.  You're suggesting the issuance could be used
to gain some sort of 'local time' relevance.

> display the time without a timezone.

NO, NO, NO.  No times without zones.

>I don't see the need to perform

An aggregator might well concern itself with issues.  Especially if
created/modified (the internal times) are not being published.

-Bill Kearney
Syndic8.com

---

From: Antone Roundy <[email-masked]>
Date: Sat, 10 Jul 2004 18:54:06 -0600

On Saturday, July 10, 2004, at 06:06  PM, Bill Kearney wrote:
> That it came from
...
> Syndic8.com

Naturally, each of us is looking at these issues from the perspective 
most relevant to us.  Machine relevance is going to be more important 
to some, and less to others, as is knowing what time of day it was 
where the author was when (s)he wrote the entry.  It sounds like we may 
have to decide who we're catering to, and whether each of the Date 
Constructs is directed at the same entity or not, in order to decide 
how to make these things work. Here's a list of involved parties, and 
what I'd guess would be preferrable to each:

1) The author: the timezone they're in when they post.
2) The publishing client software: the computer's timezone (probably 
easier to format dates in their own timezone than any other)--note: if 
the server is applying timestamps, the client software is out of the 
loop on those. Also note that if the publishing client software is web 
based, it may be hosted somewhere other than where the author is.
3) The publishing server software: the computer's timezone, or if it's 
simply accepting a timestamp given to it by the client software, then 
it doesn't much matter.
4) Aggregators: UTC--keep it all in the same timezone for easy 
processing.
5) Feed reader software: UTC--same as for aggregators.
6) Readers (people): the timezone the author was in in some cases, 
their own timezone in others (when did this get written in relation to 
the author vs. when did this get written in relation to me).

Is a timezone an accurate geo locator?  Not always, of course.  Is any 
of the content in an entry accurate?  Only as accurate as the author 
makes it.  Any of the data in a feed can be an error, a lie, an 
opinion, or a fact.  We certainly can't mandate the feeds only contain 
accurate facts.  Why not let feeds contain timezones, even though they 
may not be accurate facts?

If a person carries their laptop from one timezone to another, will 
they adjust the clock?  Maybe.  Will they do it by adjusting the 
timezone or the time?  Who knows.  If they do it by adjusting the 
clock, but have the timezone wrong, then mandating that they post in 
UTC isn't going to make the timestamp any more accurate.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 Jul 2004 19:50:43 -0700

Just a thought --

Rather than invent yet another date/time syntax, and thereby make it 
difficult for people to reuse existing software, couldn't we indicate 
that the time zone is unknown by a mechanism external to the date/time 
string?

In other words, instead of allowing a date/time string without a time 
zone, perhaps we could have a new attribute that indicates that the 
time zone isn't to be relied upon?

Something like
    <atom:issued unsureTimeZone="1">2004-02-04T10:23:45Z</atom:issued>
(use your imagination for the attribute name; this is just for colour)

Otherwise, we have to accommodate the special cases in a variety of 
ways (specs, schemas, tools, etc.).

On Jul 10, 2004, at 5:54 PM, Antone Roundy wrote:

> where the author was when (s)he wrote the entry.  It sounds like we 
> may have to decide who we're catering to, and whether each of the Date 

--
Mark Nottingham     http://www.mnot.net/

---

From: Sam Ruby <[email-masked]>
Date: Sat, 10 Jul 2004 23:35:08 -0400

Mark Nottingham wrote:
> zone, perhaps we could have a new attribute that indicates that the time 
> zone isn't to be relied upon?

We aren't inventing another date/time syntax, take a look at:

   http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime

For more details on ISO 8601, see

   http://www.qsl.net/g1smd/isopdf.htm

- Sam Ruby

---

From: Sascha Carlin <[email-masked]>
Date: Sun, 11 Jul 2004 05:37:55 +0200

Norman Walsh wrote:
> On the subject of time zones, is it really necessary to use UTC? How
> is "2004-07-08T07:11:53-04:00" really worse than
> "2004-07-08T11:11:53Z"? I can understand not using forms like
> "2004-07-08T07:11:53EDT" but I'd like the freedom to use the numeric
> forms.

As Bill and others already pointed out, we have to make a diffenrence
between machine and human read data.

We need the correct time including the timezone information for display
to humans, and we need the time in a universal format without timezone
information for machine stuff like sorting, analysing, ...

The time for humans is generated from the time plus a timezone information.

So we need to store two pieces of information: the time in UTC and the
timezone. So instead of adding x different tags to the Atom document, we
add a atom:timezone tag and can use atom:created, atom:modified (and
atom:issued, if we need to) and can create all the formats we need.

atom:timezone could have the format [+|-]dddd.dd, for instance.

Just my 2 cents.

Regards, Sascha

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 Jul 2004 20:38:35 -0700

Ah - I thought we were still using W3C datetime:
   http://www.w3.org/TR/NOTE-datetime

Never mind this, then. We should update the spec(s) to refer to Schema 
datetimes, however.

Cheers,

On Jul 10, 2004, at 8:35 PM, Sam Ruby wrote:

>> that the time zone is unknown by a mechanism external to the 
>> date/time string?

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 11 Jul 2004 12:27:46 +0200

On Sat, 10 Jul 2004 20:38:35 -0700, Mark Nottingham <[email-masked]> wrote:

>  - I thought we were still using W3C datetime:

As did I.

I, for one, don't see the problem with contiued use of W3C Datetime. It is  
easily understood and relatively easy to parse (Even when people use  
timezone offsets).

My fear with mandating UTC _and_ omitting timezone information, is that  
the ViewSourceClan are going to be putting their local time into any/all  
of created/modified/issued without aggregators/feed consumers having any  
way of knowing.

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 16:26:14 +0200

> that the time zone is unknown by a mechanism external to the date/time  

In what cases would the timezone be unknown, exactly? Just wondering.

> zone isn't to be relied upon?

Perhaps. I don't like the current state of affairs, at least, where we  
seem to be inventing our own datetime format, and violating the format we  
say we're using; W3CDTF.

> <atom:issued unsureTimeZone="1">2004-02-04T10:23:45Z</atom:issued>

Looks like a suggestion as good as any, but I just wonder what the usecase  
for not having timezone is, and why it's missing?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 16:35:46 +0200

>>  - I thought we were still using W3C datetime:

And I.

> I, for one, don't see the problem with contiued use of W3C Datetime.

Me either. It's an order of magnitude simpler than ISO 8601 (or the XML  
Schema dateTime) to understand, parse and produce correctly.

> of created/modified/issued without aggregators/feed consumers having any  

A big +1 on that one. I think we make the situation absolutely no better  
than the current state of affairs in RSS world if we don't try to be a  
little more strict and explicit on datetime usage in Atom.

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 10:46:34 -0400

> In what cases would the timezone be unknown, exactly? Just wondering.

LiveJournal.  See http://www.livejournal.com/update.bml?mode=full

In addition to newly entered dates and times, LiveJournal has a database 
full of existing dates and times with unknown timezones.

> seem to be inventing our own datetime format, and violating the format 
> we  say we're using; W3CDTF.

W3CDTF is merely a profile of ISO-8601.  ISO-8601 permits dates without 
a time zone.

> Looks like a suggestion as good as any, but I just wonder what the 
> usecase  for not having timezone is, and why it's missing?

See above.

- Sam Ruby

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 16:54:05 +0200

> atom:timezone could have the format [+|-]dddd.dd, for instance.

If it's a way to make the content of atom:timezone a valid format in  
respect to e.g. ISO 8601, then this is imho a good proposal. Authors and  
readers get what they want from having the local timezone specified, we  
don't have to create quirky date constructs or specification text, and  
aggregator writers get datetimes that's a lot nicer to work with.

A +1 to this one. Sascha; could you maybe write up a pace, so we get this  
down «on paper»?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 17:10:17 +0200

> LiveJournal.  See http://www.livejournal.com/update.bml?mode=full

Oh, okay.

> full of existing dates and times with unknown timezones.

The times in those dates is rather meaningless, aren't they? If an author  
lives in the timezone +10:00, the time '08:00' don't really mean anything.  
Therefore; would it be a solution to either:

   1) Have all users enter their timezone one place in the system, to
      change all times (and possibly dates) that user has entered?

   2) Append 'UTC' to all timezone-less dates in the database?

2) would imho not make the dates less useful than they currently are, but  
1) seems like the best solution. I think we can agree on that not storing  
timezones in LiveJournal is b0rked from the very beginning. I also hope we  
can agree on that Atom shouldn't adapt itself to b0rked implementations,  
if those implementations can be fixed.

> W3CDTF is merely a profile of ISO-8601.

Yes, but it's a neat and extremely simple profile that I think fits Atom  
pretty much like a hand in a glove.

> ISO-8601 permits dates without a time zone.

I know, but imho Atom shouldn't. There are cases where one would want to  
conform to ISO-8601 and not store timezone, e.g. in an publishing system  
only intended for local customers. But whenever you're talking about  
exchanging information across borders, the timezone informatin is not only  
important, but vital to the date stored with the information.

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 11:33:22 -0400

Asbjørn Ulsberg wrote:

> I 
> also hope we  can agree on that Atom shouldn't adapt itself to b0rked 
> implementations,  if those implementations can be fixed.

Let's try to avoid terms like b0rked, and if you would like people to be 
respectful of limitations that affect you (example: 
<http://www.imc.org/atom-syntax/mail-archive/msg05239.html>), then 
perhaps taking the time to understand the perspective of others.

LiveJournal has a large customer base, who to date have seen value in 
expressing time in relative and personal terms.  To live journal users, 
knowing that an entry was penned at 2am in the subjective frame of 
reference of the author is much more significant piece of information 
than knowing what this time corresponds to in a canonical time 
corresponding to a place in a country that they may never visit.

- Sam Ruby

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 17:53:58 +0200

On Sun, 11 Jul 2004 11:33:22 -0400, Sam Ruby <[email-masked]>  
wrote:

> Let's try to avoid terms like b0rked

Very true. Sorry about that.

> then perhaps taking the time to understand the perspective of others.

Agreed, although I hope someone would agree that the situation of  
LiveJournal is easier to «fix» than the situation for the unpriviledged  
users[1]. To make the entries in LiveJournal work with a stricter datetime  
format in Atom, we «just» need the users to enter their timezone offset,  
and all their entries can be served with the offset information as  
supplied, or converted to UTC.

> expressing time in relative and personal terms.

Though this perspective is incomprehensible to me, I accept that this is  
the current situation, but I hope that it can be worked on to make it  
better and easier for other tools to work with LiveJournal's entry dates.

> To live journal users, knowing that an entry was penned at 2am in the
> subjective frame of reference of the author is much more significant
> piece of information than knowing what this time corresponds to in a
> canonical time corresponding to a place in a country that they may
> never visit.

And that's something I can understand, but outside the author's very  
narrow worlds, the timezone is very important. While '08:00' means «08:00  
where I live» for the author and some of its audience, it doesn't mean  
diddlysquat to everyone else. Therefore, I think we need timezone in the  
entries. Either as '+10:00' in the date constructs, or as Sascha Carlin  
proposed; in a separate element.

This way, the authors can still express what time of the day in their  
local time the entry was written, as well as providing useful information  
to aggregator tools trying to (automatically) do something fun with their  
entries.

____
[1] <url: http://intertwingly.net/wiki/pie/UnprivilegedUsers>

---

From: [email-masked]
Date: Sun, 11 Jul 2004 08:55:34 -0700 (PDT)

> corresponding to a place in a country that they may never visit.

I agree 100% with this sentiment. Knowing that something was written at 3:00AM
local can be just as important as knowing exactly when something was written.

				Ned

---

From: Robert Sayre <[email-masked]>
Date: Sun, 11 Jul 2004 12:05:15 -0400

> corresponding to a place in a country that they may never visit.

http://diveintomark.org/archives/

If Atom doesn't have subjective dates, Mark will have to tweak time stamps
to move entries around in the archives. Instead of changing a subjective
field, people will falsify "objective" ones. Now that's b0rked.

Robert Sayre

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 18:11:16 +0200

On Sun, 11 Jul 2004 08:55:34 -0700 (PDT), <[email-masked]>  
wrote:

> I agree 100% with this sentiment. Knowing that something was written at  
> 3:00AM local can be just as important as knowing exactly when something
> was written.

Okay, I see the use case, but does it matter to the author if it the time  
is expressed as '03:00+10:00' or '03:00'?

---

From: [email-masked]
Date: Sun, 11 Jul 2004 09:13:10 -0700 (PDT)

> is expressed as '03:00+10:00' or '03:00'?

Presumably the author knows what time zone they're in when the write the
message, so no, it doesn't matter to the author at the time. OTOH, since
computer systems not infrequently botch time zone settings  showing the author
the time zone that's in effect isn't a bad thing to do. I've caught config
problems this way more than once. (Although for J Random User to catch config
errors they may need to see PDT/PST/whatever and not +/-nn:nn.)

				Ned

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 18:32:13 +0200

On Sun, 11 Jul 2004 09:13:10 -0700 (PDT), <[email-masked]>  
wrote:

>> Okay, I see the use case, but does it matter to the author if it the  
>> time is expressed as '03:00+10:00' or '03:00'?
>
> message, so no, it doesn't matter to the author at the time.

Right. Would it be too much to ask of LiveJournal to have their users  
enter their timezone once, to have the LiveJournal entry's dates conform  
to a stricter specified date construct (requiring timezone) in Atom? I  
don't think that's asking for much.

> OTOH, since computer systems not infrequently botch time zone settings
> showing the author the time zone that's in effect isn't a bad thing to
> do.

True. That would indeed be useful information to a lot of authors.

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 12:31:13 -0400

Asbjørn Ulsberg wrote:
> users[1]. To make the entries in LiveJournal work with a stricter 
> datetime  format in Atom, we «just» need the users to enter their 
> timezone offset,  and all their entries can be served with the offset 
> information as  supplied, or converted to UTC.

Fixing a server is always possible.  Fixing a historical database may 
not be.

> Though this perspective is incomprehensible to me, I accept that this 
> is  the current situation, but I hope that it can be worked on to make 
> it  better and easier for other tools to work with LiveJournal's entry 
> dates.

We need to better define what we expect people who "work with" these 
dates can expect.  I explored this in

http://www.intertwingly.net/blog/2003/07/01/Subjective-and-objective-dates

And I suspect that the opening paragraph in that blog entry applies here:

     In TimestampVsCreationDateTime there are a number of votes for each
     of the 'alternatives'.  In cases like this, I suspect that what is
     really going on is that people are talking about multiple distinct
     things.

There is no question in my mind that <modified> dates should be strictly 
ordered, so either an indication of timezone or canonicalization to UTC 
would be required.  Doing so would allow aggregator authors to order 
entries across all weblogs, if they chose to do so.

What Bloggers calls Post Date and Time [1], and what LiveJournal simply 
calls Date and Local Time of an entry is different.  Qualitatively 
different.  It is subjective.  It's primary purpose is for display.  For 
human consumption.

Note that in both Blogger and LiveJournal, this latter field is 
something that the user can control.  In Blogger, this field can even be 
changed after the fact.

The most you can assume about this particular date is that it is the 
date that the author wants associated with the entry, nothing more, 
nothing less.

Like the August issue of Sports Illustrated that may be on your 
newsstands now, or that blog entry that you may have written up 
yesterday - about events that took place yesterday - but somehow didn't 
get posted to your site until this morning.

One date is objective, intended to be processed by cold hard machines. 
One date is subjective, intended to be processed by warm squishy humans.

I don't know if these two concepts have exact equivalents in Dublin 
Core.  I know that these concepts are not well explained in the current 
drafts.  I doubt that any of the current Paces adequately captures this.

But I do know that a number of blog vendors model things this way.  And 
don't view it a bug.

- Sam Ruby

[1] http://help.blogger.com/bin/answer.py?answer=139&topic=17

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 11 Jul 2004 14:26:43 -0400

> (Although for J Random User to catch config

And as long as the developers understand that PDT/PST mean -07:00/-08:00.  It
varies based on the /date/ involved.

Take, for example, Noon in LA:

07/01/2004 12:00PDT is 07/01/2004 19:00Z
(seven hours off UTC during DST)
but
12/01/2004 12:00PST is 07/01/2004 20:00Z
(eight hours off during standard time)

This is also why it's often a better idea all around to store in UTC.  Doing
'date math' across ranges when you cross daylight savings periods can often have
unexpected results.  As in, converting a timestamp from outside your current
shift (May during December, and vice versa).

Oh, and to make matters worse, not all areas/countries observe DST
"consistently".  Thus flipping the date to UTC as quickly as possible in the
collection process makes a whooooole lot of sense.

-Bill Kearney

---

From: Sascha Carlin <[email-masked]>
Date: Sun, 11 Jul 2004 20:32:28 +0200

Asbjørn Ulsberg wrote:

> A +1 to this one. Sascha; could you maybe write up a pace, so we get 
> this  down «on paper»?

Sorry, I only follow this mailinglist, well, very roughly ;) Please do 
whatever you want or tell me what to do.

Regards, Sascha

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 11 Jul 2004 21:10:56 +0200

> Fixing a server is always possible.  Fixing a historical database may  

My hunch is that if Livejournal asks their users once about providing
correct time zone information, and correct the dates on their entries
accordingly, 99% of LiveJournal dates will be "reasonably valid".

Without disrespecting LiveJournal, I think omitting timezone info for the
sake of one vendor is going to keep us in all sorts of trouble for years
to come.

(Besides: How likely are the old entries to reappear in any feed?)

-- 
Arve Bersvendsen

---

From: Ken MacLeod <[email-masked]>
Date: 11 Jul 2004 14:21:46 -0500

> (Besides: How likely are the old entries to reappear in any feed?)

Atom is an archiving format as well as a feed format, even if we
haven't addressed some of the archiving issues yet.

  -- Ken

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Sun, 11 Jul 2004 15:58:03 -0400

There's something else to consider when trying to decide upon a date-time
format for use in IETF protocols, and that's re-use of earlier IETF work.  I
know that you're all considering earlier W3C work, so please check this out
as well:

ftp://ftp.rfc-editor.org/in-notes/rfc3339.txt

I can guarantee that your AD will eventually ask why an existing format
wasn't referenced if you all decide to do something new.

-Scott-

---

From: Norman Walsh <[email-masked]>
Date: Sun, 11 Jul 2004 16:28:59 -0400

/ "Scott Hollenbeck" <[email-masked]> was heard to say:
| There's something else to consider when trying to decide upon a date-time
| format for use in IETF protocols, and that's re-use of earlier IETF work.  I
| know that you're all considering earlier W3C work, so please check this out
| as well:
|
| ftp://ftp.rfc-editor.org/in-notes/rfc3339.txt
|
| I can guarantee that your AD will eventually ask why an existing format
| wasn't referenced if you all decide to do something new.

I would support a normative reference to this RFC for specifying all
of the date/time values in Atom.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Until death, it is all life.-- Cervantes
http://nwalsh.com/            |

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 16:34:32 -0400

> wasn't referenced if you all decide to do something new.

Thanks!  That is *very* helpful.  What I have gathered from a quick scan:

This document essentially indicates that the IETF now feels (as of 2002) 
that ISO 8601 is a better base than RFC 822/2822 for date formats in new 
protocols (feel free to correct me if I am overstating this).

For interoperability reasons, the IETF defined a profile of ISO 8601. 
This profile is *much* more restrictive than the one in W3CDTF.  As an 
example, here is a valid W3CDTF date-time:

   1997

In rfc 3339 dates, everything is mandatory except fractions of seconds, 
and the only option is the use of "Z" in place of a time-numoffset.

The wording in section 4.4 against unqualified local times is fairly strong.

- Sam Ruby

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 11 Jul 2004 22:57:54 +0200

>  The wording in section 4.4 against unqualified local times is fairly  

Also, in section 4.3:

    If the time in UTC is known, but the offset to local time is
    unknown, this can be represented with an offset of "-00:00".

Will this be able to (partly) solve LiveJournal's archive problems?

-- 
Arve Bersvendsen

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 11 Jul 2004 17:01:52 -0400

> Atom is an archiving format as well as a feed format,

Since when?

> even if we haven't addressed some of the archiving issues yet.

Indeed, works from the folks at NARA [1] would well be worth consulting before
rampant wheel reinventing get underway.

-Bill Kearney

[1] http://www.archives.gov/

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 11 Jul 2004 17:04:48 -0400

> (Besides: How likely are the old entries to reappear in any feed?)

I second both comments.  Also, LJ is 'relatively' centrialized, is it not?  Much
like blogger it's therefor likely that a small set of fixes could be implemented
that eliminate and so-called legacy issue.

Sure, the "LJ community" is likely to express certain amounts of "opinion" about
it but probably nowhere near the hand-wringing cited around here.

Let's not be too hasty to beat /anyone/ up about it though.  The timezone stuff
is enough to give anyone a migraine.  If something 'got it wrong' then let's
help them 'get it right'.

-Bill Kearney
Syndic8.com

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 11 Jul 2004 17:04:25 -0400

> and the only option is the use of "Z" in place of a time-numoffset.

Yes, I think most folks, when referencing 'w3cdtf' were talking about that which
parallels the 8601 profile.

-Bill
(who hopes this drives a final stake in the heart of x822 format)

---

From: Sascha Carlin <[email-masked]>
Date: Sun, 11 Jul 2004 23:10:48 +0200

> The wording in section 4.4 against unqualified local times is fairly 

Sorry: what exactly are 'unqualified local times'? Times without correct 
timezone information?

Seconding my last post 
(http://www.imc.org/atom-syntax/mail-archive/msg06542.html): From a 
software author's/machine's point of view, having time and timezone 
information readily seperated would be a great thing. Otherwise you 
would have to do a lot of wugga wugga to generate all needed formats.

Regards, Sascha

---

From: Graham <[email-masked]>
Date: Sun, 11 Jul 2004 17:24:33 -0400

On 11 Jul 2004, at 4:57 pm, Arve Bersvendsen wrote:

>> In rfc 3339 dates, everything is mandatory except fractions of 
>> seconds, and the only option is the use of "Z" in place of a 
>> time-numoffset.

No, since the time is not known in UTC, only in an unknown local 
timezone.

Graham

---

From: Ken MacLeod <[email-masked]>
Date: 11 Jul 2004 16:31:22 -0500

> > Atom is an archiving format as well as a feed format,

Since inception,

  http://intertwingly.net/wiki/pie/RoadMap

and it's in our charter,

  http://ietf.org/html.charters/atompub-charter.html

> Indeed, works from the folks at NARA [1] would well be worth
> consulting before rampant wheel reinventing get underway.

I'm not seeing any particular specs there to learn from, pointers?

The use-case for the archive format is to export/import a site.  The
back-of-the-envelope current solution is one big <feed>.  Another
use-case is back-history for a site, by using an organization of
mostly static <feed> resources as an index to all entries, with
prev/next and side links.

There are issues in the index and "big" archive feed that, for
example, may be helped by recent discussion on separating "site" or
"feed" information from the "physical" feed structure.  The issue of
storing non-entry resources in an archive is a biggy, for the archive
profile we most likely will have to use a MIME container.

  -- Ken

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 17:48:21 -0400

Graham wrote:

> No, since the time is not known in UTC, only in an unknown local timezone.

My read of section 4.3 is that RFC 3339 defines "+00:00" and "-00:00" to 
have different semantic meanings: the former equating to "UTC", the 
latter equating to "Unknown Local Offset".

Undoubtably software which can not deal with the concept of dates 
without timesones will read such dates and assume UTC.  All things 
considered, this is not the worst assumption that can be made.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Sun, 11 Jul 2004 18:00:52 -0400

On 11 Jul 2004, at 5:48 pm, Sam Ruby wrote:

> My read of section 4.3 is that RFC 3339 defines "+00:00" and "-00:00" 
> to have different semantic meanings: the former equating to "UTC", the 

But to use either you still need to know the correct time in UTC - 
"+00:00" implies the author is located near the Greenwich Meridian, 
"-00:00" doesn't. It's different from the Livejournal problem.

Graham

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 18:13:24 -0400

> "-00:00" doesn't. It's different from the Livejournal problem.

I agree with everything but the last sentence.

+00:00 implies the author is located near the Greenwich Meridian.

-00:00 does not imply where the author is located.

LiveJournal has recorded some dates where they don't know where the 
author is located.

An example livejournal feed can be found at

http://www.livejournal.com/users/brad/data/atom

Note that value of <issued> in (what is now) the first entry is 
"2004-07-10T16:47:00".  My read of RFC 3339 is that this information 
would need to be represented as "2004-07-10T16:47:00-00:00" in order to 
express the concept that this time is in an unknown local timezone offset.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Sun, 11 Jul 2004 18:20:09 -0400

> LiveJournal has recorded some dates where they don't know where the 

But they don't know how to correctly convert them to UTC (do they?), 
which is a requirement of using "-00:00". I think LiveJournal falls 
under section 4.4 "Unqualified Local Time".

> would need to be represented as "2004-07-10T16:47:00-00:00" in order 
> to express the concept that this time is in an unknown local timezone 
> offset.

I don't think that does represent 16:47 UTC +/- up to 12 hours. It 
represents 16:47 UTC exactly - the location is the only thing unknown.

Graham

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 11 Jul 2004 18:39:08 -0400

> represents 16:47 UTC exactly - the location is the only thing unknown.

NO, timezones are NOT geographic data.  They don't denote "where" something is
located.  Let's just get off that line of thinking right away.  If location info
is desired it's a whole other can of worms.

It does NOT represent 16:47 at UTC.  It represents 4:47 pm in some unknown
timezone and cannot be expressed as a timestamp.

-Bill Kearney

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 11 Jul 2004 18:41:11 -0400

> to aggregator tools trying to (automatically) do something fun with their

The arguments against using timestamps with or without zone suffiixes is the
root of much confusion.

If an implementation can't make a timezone assertion then it has no hope, and
workarounds are a hopeless quagmire.

Yes, it's useful to see that an item has a timestamp of "the middle of the
night, local time".  It often adds a bit of subjectivity to the process that
might be lacking otherwise.  As in, middle of the night Friday might explain
someone being drunk off their ass when they posted something.  Of course knowing
the poster's a boozehound 24x7 might be the edge case against it however.
Regardless, if consistency and ACCURATE understanding of timezones is encouraged
then this is all largely a non-issue.  This is something the developers can
spend a trivial amount of time coding and forever be DONE with it.

But if the nonsense of coddling un-zoned timestamps is tolerated then the chaos
will continue.  It's really NOT that hard folks, fix the code and MOVE ON.

-Bill Kearney
Syndic8.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 00:50:44 +0200

> whatever you want or tell me what to do.

Recent discussions on #atom has lead to PaceDates[1] which bases the Date  
Construct in Atom on RFC 3339, which requires timezone on all dates.  
Therefore, a separate element for the timezone is not required anymore. At  
least not if the Pace is accepted.

____
[1] <url: http://intertwingly.net/wiki/pie/PaceDates>

---

From: Walter Underwood <[email-masked]>
Date: Sun, 11 Jul 2004 16:06:03 -0700

> (use your imagination for the attribute name; this is just for colour)

Excellent idea.

We do want to use these untrustworthy times to order the entries
in one blog and to display times, but we can't trust them for
inter-blog ordering. The maximum uncertainty is +/-24 hours.
Maybe +-26 with worst-case summer/daylight time.

I really like the idea of a display timezone. UTC is for computers,
timezones are for people. So Atom must communicate dates in UTC
and should provide timezone prettyfication hints.

Funny, this is just like an undated entry in a paper diary. The order
is certain, but the exact time isn't.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 01:50:10 +0200

>>     <atom:issued unsureTimeZone="1">2004-02-04T10:23:45Z</atom:issued>

Although much better expressed as '2004-02-04T10:23:45-00:00' as stated in  
RFC 3339 section 4.4.

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 19:51:53 -0400

> under section 4.4 "Unqualified Local Time".

I've gone back and reread this section more carefully, and now concur 
with your interpretation.

Oddly, this is 180 degrees off of where the threat indicated by this 
subject line started.  The premise of this RFC seems to be that time 
zones are useful information and should be included whenever possible. 
"-00:00" seems to be a way to indicate that this information is lost.

In any case, I now agree that this does not address LiveJournal's needs.

- Sam Ruby

---

From: Walter Underwood <[email-masked]>
Date: Sun, 11 Jul 2004 15:00:29 -0700

> I'm not seeing any particular specs there to learn from, pointers?

Encoded Archival Desciription (EAD) is where I would start:
<http://www.loc.gov/ead/>

But archives have a much, much more difficult problem than Atom
is addressing. Dates may be uncertain, with a wide range, months,
decades, or even centuries. They need to deal with local calendars,
like the French Revolutionary calendar. What about magazines where
the release date is months apart from the cover date?

Still, library technology and practice is very effective, and we
need to learn from it.

wunder

---

From: Walter Underwood <[email-masked]>
Date: Sun, 11 Jul 2004 17:26:23 -0700

--On Monday, July 12, 2004 1:50 AM +0200 Asbjørn Ulsberg <[email-masked]> wrote:
>
> On Sun, 11 Jul 2004 16:06:03 -0700, Walter Underwood <[email-masked]>  wrote:
>
> Although much better expressed as '2004-02-04T10:23:45-00:00' as stated
> in  RFC 3339 section 4.4.

Treating negative zero differently raises the hairs on the back of
my neck, but since it is standard, I guess it is OK. I must be having
some vicarious flashback to sign-magnitude machine architectures,
even though I've never done acid or integer sign bits.

We will have to rewrite some code to discard timestamps with
-00:00 timezone offsets, but it is minor. My instinct is that
when the indexer sees one of those, it will discard it and choose
the next most reliable source. It isn't feasible to modify the
whole search engine to handle date+certainty.

wunder

---

From: "Roger B." <[email-masked]>
Date: Sun, 11 Jul 2004 19:21:13 -0500

> (Besides: How likely are the old entries to reappear in any feed?)

Arve: I'm not LiveJournal, but:

Standard feed:
http://admin.support.journurl.com/?template=rss

Feed for July 2003:
http://admin.support.journurl.com/?month=07-31-2003&template=rss

Search feed for term "blogs":
http://admin.support.journurl.com/?mode=search&s=blogs&template=rss

The latter two return old entries galore.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 20:23:12 -0400

Sam Ruby wrote:
> subject line started.

Oopsie.  s/threat/thread/.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Sun, 11 Jul 2004 20:41:28 -0400

> whole search engine to handle date+certainty.

Erm, why? Maybe Sam and Bill have confused you. -00:00 means the point 
in time the event happened is known, but the timezone it happened in 
isn't (ie The UTC time is known, the local time isn't). There's no need 
to discard it unless you're desperate for the local time of the event.

Graham

---

From: Walter Underwood <[email-masked]>
Date: Sun, 11 Jul 2004 17:52:15 -0700

> to discard it unless you're desperate for the local time of the event.

First, the application -- I expect to use Atom feeds to: 1) direct the
search engine spider to interesting content, and 2) provide quality
metadata for those targets.

The -00:00 timestamps have a large error. Either I change the software
to carry around error estimates for all timestamps and choose the best,
or we throw away the bad ones early on. HTTP timestamps are implicitly
exact, so they always win. Thus, we throw away all -00:00 timestamps
from Atom.

I'm quite familiar with timezone issues. We provide search for
worldwide companies, so queries for "changed in the last day"
need to work regardless of timezone. Timezones are a tar pit.

wunder

---

From: Dan Brickley <[email-masked]>
Date: Sun, 11 Jul 2004 20:57:23 -0400

* Walter Underwood <[email-masked]> [2004-07-11 15:00-0700]
> like the French Revolutionary calendar. 

It isn't clear to me that Atom/RSS/etc should avoid this issue. There
are 1000s of Iranian blogs whose dates are published and consumed in
terms of the Persian calendar. I'd hope at least for non-gregorian dates 
to be expressible using extensions in another namespace; when Atom's 
namespace extension policy is nailed down, perhaps we might revisit this
topic?

>					What about magazines where

Most certainly...

Dan

---

From: Walter Underwood <[email-masked]>
Date: Sun, 11 Jul 2004 18:02:09 -0700

> namespace extension policy is nailed down, perhaps we might revisit this

Good point. Perhaps a utc-date and optional display-date for each value?
They MUST be equivalent, of course.

wunder

---

From: Graham <[email-masked]>
Date: Sun, 11 Jul 2004 21:18:20 -0400

On 11 Jul 2004, at 8:52 pm, Walter Underwood wrote:

> The -00:00 timestamps have a large error.

No they do not. A -00:00 timestamp is as accurate as one with +00:00. 
The difference is that the *originating* timezone is unknown. 
12:00-00:00 could really be 08:00-4:00 or 17:00+5:00, but whatever, 
it's still noon UTC. When normalizing for a search engine, you don't 
have a problem.

Graham

---

From: Walter Underwood <[email-masked]>
Date: Sun, 11 Jul 2004 19:17:57 -0700

--On Sunday, July 11, 2004 9:18 PM -0400 Graham <[email-masked]> wrote:
> The difference is that the *originating* timezone is unknown. 12:00-00:00
> could really be 08:00-4:00 or 17:00+5:00, but whatever, it's still noon
> UTC. When normalizing for a search engine, you don't have a problem.

You are right. I didn't read RFC 3339 closely. Sorry. I was catching
up on 275 new messages.

Local clock time with an unknown timezone cannot be represented in
RFC 3339 formats. So old LiveJournal timestamps cannot be sent in
Atom if we require RFC 3339.

wunder

---

From: Ken MacLeod <[email-masked]>
Date: 11 Jul 2004 21:26:55 -0500

Walter Underwood <[email-masked]> writes:

> But archives have a much, much more difficult problem than Atom is
> addressing. Dates may be uncertain, with a wide range, months,

I may be misunderstanding the scope of this suggestion.

The scope I'm describing is the "export" of an Atom publishing system,
either of the whole system (an "archive" of the Atom publishing
system), or an "index" structure (as described in "Catching up on
missed news"[1]).

Within this scope, the "archive" or "index" contain the same <entry>
resources as appear in feeds (possibly with additional information,
like source formatted content).

If these other archiving technologies are more appropriate for that
purpose, it's likely that they are more appropriate model for <entry>s
that we use in feeds, too.

Please advise,

  -- Ken

[1] http://www.xml.com/pub/a/2004/06/16/dive.html

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 04:57:49 +0200

On Sun, 11 Jul 2004 19:17:57 -0700, Walter Underwood <[email-masked]>  
wrote:

> So old LiveJournal timestamps cannot be sent in Atom if we require
> RFC 3339.

Correct. Old LiveJournal timestamps should therefore be fixed.

---

From: Martin Duerst <[email-masked]>
Date: Mon, 12 Jul 2004 14:02:48 +0900

>namespace extension policy is nailed down, perhaps we might revisit this

I doubt that's actually necessary. What should be possible is for
end users preferring non-gregorian calendars to input their dates in
their calendar of preference, and to see all the dates in a calendar
format of their preference.

Data interchange is much better limited to a very limited
ISO 8601-based W3C/XSD/IETF/... format. What we might think
about are extensions to define ranges rather than timestamps,...

Regards,    Martin.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 12 Jul 2004 08:17:03 -0600

> collection process makes a whooooole lot of sense.
Requiring use of numeric offsets rather than "PST", etc., solves the 
problem too.  Of course, the software may wish to let the user indicate 
"PST" in case they don't know how many hours they are offset from 
UTC--but the software should publish the feed with a numeric offset.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 12 Jul 2004 09:35:19 -0600

...
> There is no question in my mind that <modified> dates should be  
> strictly ordered, so either an indication of timezone or  
> canonicalization to UTC would be required.  Doing so would allow  
> aggregator authors to order entries across all weblogs, if they chose  
> to do so.
>
> What Bloggers calls Post Date and Time [1], and what LiveJournal  
> simply calls Date and Local Time of an entry is different.   
> Qualitatively different.  It is subjective.  It's primary purpose is  
> for display.  For human consumption.
...
...

On Sunday, July 11, 2004, at 10:46  PM, Graham wrote:
> A major change should result in a new atom:issued

Okay, here's an attempt at a methodical approach to defining what date  
elements we need and what the requirements and recommendations should  
be for each.

Dates (where "date" = "date and time") that might be associated with an  
entry:

1) objective creation date
2) each objective major modification date
3) each objective minor modification date
4) each objective publication date
5) any subjective creation date the author may wish to associate with  
the entry
6) any subjective major modification date the author may wish to  
associate with the entry
7) any subjective minor modification date the author may wish to  
associate with the entry
8) any subjective publication date the author may wish to associate  
with the entry

Questions:
A) Which of these should appear in the feed?
B) Which of these can be consolidated into a single element in a feed?
C) What timezone requirements/recommendations should each carry?

Interested parties:
I) Author: Most interested in 8. Prefers their local timezone.
II) Publishing client software: Just an intermediary--probably doesn't  
care about anything.
III) Publishing server software: Most interested in 2-4, possibly  
including all iterations. No strong timezone preference.
IV) Aggregators: Most interested in 2-4, perhaps including only the  
first, last, or first and last of each. Perfers UTC.
V) Feed reader software: Most interested in 2-3 for ordering and  
determining whether to call something "new" or "updated". No strong  
timezone preference.
VI) Human reader: Most interested in the last of each in 2-3 and one of  
4 or 8 (depends on the person)--possibly also interested in the first  
of 4 or 8--and may wish the timezone to be either the author's local  
timezone or their own local timezone.

Comments (correct me if I'm wrong or you disagree--these are my  
perceptions and opinions):
i) The publishing software can store the dates in whatever timezone  
they want. They can present it to the author in the author's local  
timezone, and can publish it as best benefits everyone else.
ii) Nobody really cares about 5-7.
iii) Nobody reading the feed really cares about 1, so including it in  
the feed should be optional. I suppose there may be uses for it, but I  
wouldn't complain if it weren't even supported.
iv) Nobody reading the feed cares much about anything that occurred  
before the first 4.

Conclusions:
a) 2-4 and 8 are the only dates that may need to be in the feed.
b) At most the first and last of each should appear in the feed.
c) Only 8 should be allowed to omit the timezone.
d) 2 could be used instead of 4 in the feed.

Proposed Date Constructs:

atom:first-issued or atom:first-published (first 4)
	An objective publication date. REQUIRED. MUST specify a timezone  
(which might be -00:00 if the timezone is unknown) which MUST be  
numeric.

atom:issued or atom:published (last 8)
	A subjective publication date. OPTIONAL. It is RECOMMENDED that it  
include a timezone, that the timezone be numeric, and that it be the  
author's timezone, or the timezone relevant to the content of the entry  
(for example, if I, in Utah, am writing about something that happened  
in Iraq, I might use Iraq's timezone).

atom:modified (last 2)
	The objective date when the last major change--a change which alters  
or non-trivially expands the message--was made to the entry. REQUIRED  
if different from atom:first-issued|published. It MUST specify a  
timezone (which might be -00:00 if the timezone is unknown), which MUST  
be UTC.

atom:updated (last 3)
	The objective date when the last minor change--for example a spelling  
correction, clarification which doesn't expand the message, etc.--was  
made to the entry. RECOMMENDED if different from  
atom:first-issued|published and later than atom:modified. MUST NOT be  
included if earlier than atom:modified. MUST specify a timezone (which  
might be -00:00 if the timezone is unknown), which MUST be UTC.

I would also propose that the spec text for each Date Construct, or  
some text appearing before the list of Date Constructs, point out that  
the requirements for each are different because some are intended to  
use by software and others for presentation to humans.

The "objective" dates should have spec text to point out that these  
dates MUST NOT be modified except to correct for errors in the actual  
timestamp (for example, if the computers clock was incorrect).

Note that the dates that are required to be specified in UTC may be  
converted by client software to the timezone indicated in  
atom:issued|published if it appears in the feed. All dates may also be  
converted to the user's local timezone.

---

From: "Roger B." <[email-masked]>
Date: Mon, 12 Jul 2004 11:29:27 -0500

> 	An objective publication date. REQUIRED
> 
> 	A subjective publication date. OPTIONAL.

Antone: This is an example of setting up a self-defeating scenario. Few (if
any) blogapps track an objective publication date... they're generally
subjective. So subjective dates will simply be slammed into the required
element, and the optional element will be considered superfluous. Atom
consumers, in turn, will simply ignore the spec and assume that first-issued
is a subjective date.

If folks absolutely must have some sort of immutable publishing date, then
it will have to be optional. Or better yet, just give atom:issued an
optional atom:objective="true|false" attribute, with the attribute
defaulting to "false".

---

From: Antone Roundy <[email-masked]>
Date: Mon, 12 Jul 2004 10:59:22 -0600

> consumers, in turn, will simply ignore the spec and assume that 

Good point--I was being overly idealistic.  How about making 
atom:issued REQUIRED and atom:first-issued RECOMMENDED, at least if 
different from atom:issued or if atom:issued doesn't specify a numeric 
timezone.  I've gotten the impression from some of the discussion here 
that this information would be desirable (and I myself would consider 
it useful), so if it's not currently tracked by blog apps, perhaps this 
is an opportunity to encourage an improvement.

---

From: Sam Ruby <[email-masked]>
Date: Mon, 12 Jul 2004 12:56:45 -0400

I like the below so much that I am republishing it with a new subject line.

What I like is the methodical approach.  I don't believe that the names 
of these proposed elements are anything more than something to seed the 
discussion.  And may of the specifics are subject to discussion, but 
this is an excellent way to approach the problem.

- Sam Ruby

Antone Roundy wrote:
>> One date is objective, intended to be processed by cold hard 
>> machines.  One date is subjective, intended to be processed by warm 
>> squishy  humans.
> 
> 
> (which might be -00:00 if the timezone is unknown) which MUST be  numeric.
> 
>     The objective date when the last major change--a change which 
> alters  or non-trivially expands the message--was made to the entry. 
> REQUIRED  if different from atom:first-issued|published. It MUST specify 
> a  timezone (which might be -00:00 if the timezone is unknown), which 
> MUST  be UTC.
> 
> atom:updated (last 3)
>     The objective date when the last minor change--for example a 
> spelling  correction, clarification which doesn't expand the message, 
> etc.--was  made to the entry. RECOMMENDED if different from

---

From: Graham <[email-masked]>
Date: Mon, 12 Jul 2004 13:38:25 -0400

On 12 Jul 2004, at 12:56 pm, Sam Ruby wrote:

> What I like is the methodical approach.  I don't believe that the 
> names of these proposed elements are anything more than something to 
> seed the discussion.  And may of the specifics are subject to 
> discussion, but this is an excellent way to approach the problem.

I think the list of dates is way too abstract to be useful. As an 
aggregator author, I am only interested in one, maybe 2 dates:

1) The date I would have first found the entry had I been checking once 
a minute
2) A date to show the user, usually the same as above

There is an exception to number 1. Sometimes an old entry will reappear 
in a feed, usually because it has been updated. Most sites don't do 
this - their feed is fixed as the last n entries by creation date, 
which is fine. But when a site does do this, I consider it as 
significant as publishing a new entry. So I am not *at all* interested 
in the date of minor or major modifications, but I am interested in 
when the publisher deliberately bounces an old entry back to the top of 
their list. Re-issuing is much more significant than modification.

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 19:52:02 +0200

On Mon, 12 Jul 2004 11:29:27 -0500, Roger B. <[email-masked]>  
wrote:

> Few (if any) blogapps track an objective publication date...

Okay. I just have to ask. Is it consensus that Atom should:

   1. Only cater for the blogging community.
   2. Only cater for existing blogging tools.
   3. Just adopt current (bad) practices and not try to do anything to
      improve the quality of service or data in the syndication sphere.

If not, what does it matter that blog applications have bad practice on  
this field? Have you thought about how incredibly simple it is to  
implement a 'first-issued' or 'first-published' in a tool? It's one extra  
field in the data storage and one statement in SQL, if the storage is an  
RDBMS. This would take me less than two minutes to implement in my tool.

Okay, that won't do for existing blog applications, but that's a symptom  
and not the problem itself. We have to deal with that and instead try to  
aim a bit higher in our search for the «best» solution. We are sure to  
wind up with a crap solution if that's what we're aiming for.

Making Atom require 'first-issued' or 'first-published' would elevate the  
data quality a great number of notches, and I can't see why that's a bad  
thing. In Atom today, people already have to provide an 'atom:issued'. If  
you're having problems with providing a 'first-issued', then you're having  
problems with providing 'issued' as well, and thus you're serving an  
invalid Atom feed.

If you indeed are serving 'issued' correctly, 'first-issued' is just the  
first instance of all the possible values in 'issued'. E.g. 'first-issued  
= issued'. The former can't change while the latter can.

Also, I'd like to note that most of the large CMS's I've had my hands on,  
already supports this. Why this cares goes to point 1) and 2) in the above  
list. If Atom is supposed to cater something else than the extreme narrow  
and poor metadata-quality blogging community, it should provide mechanisms  
to not only allow for, but _promote_, high quality data.

As of now, Atom not only makes (high) quality data optional, it promotes  
bad quality data. How can we ever expect the data quality to improve if we  
encourage people to continue to spew out bad data?

> they're generally subjective.

Yes, and see how wonderful that's worked out for LiveJournal.

> So subjective dates will simply be slammed into the required
> element, and the optional element will be considered superfluous.

Yes, please fill the format with the _least_ trustworthy and reliable  
information, and leave all the reliable stuff out. Heck, even make the  
unreliable information _required_, and the reliable information highly  
optional. Yay!

> Atom consumers, in turn, will simply ignore the spec and assume that  
> first-issued is a subjective date.

Uh. Okay? I'm an Atom consumer, and I would _never_ expect 'first-issued'  
to be subjective. Even less so 'first-published' or 'published'. Not more  
than 'modified' or 'created', at least. Up until the date discussion  
surfaced just recently, I actually thought all Atom dates were objective.  
I'm still amazed that's not the case.

> If folks absolutely must have some sort of immutable publishing date,  
> then it will have to be optional.

Then it's useless, really. The whole point in having such a reliable date  
would be to actually be able to count on it (being there. Always).

> Or better yet, just give atom:issued an optional
> atom:objective="true|false" attribute, with the attribute
> defaulting to "false".

Then, Ken's profile proposal is a much better idea. I still hope we can do  
better than that and not only cater for current bad implementations,  
though.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 04:07:43 +1000

On 13/7/04 3:52 AM, "Asbjørn Ulsberg" <[email-masked]> wrote:

> Up until the date discussion  surfaced just recently, I actually thought all
> Atom dates were objective.  I'm still amazed that's not the case.
> 
you've not been following the career of Samuel Pepys then?

e.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 12 Jul 2004 14:43:12 -0600

On Monday, July 12, 2004, at 11:38  AM, Graham wrote:
> I think the list of dates is way too abstract to be useful.
Yes, I agree that the initial list of 8 contains a LOT more dates than 
we want in the feed.  The purpose of the list is merely to create a 
(hopefully) comprehensive list of POSSIBLE dates, where there's no 
ambiguity about what EXACTLY we mean when we refer to one of them, for 
us to whittle down to what we want.  For example, I think we have a 
pretty good idea of what the term "issued" means, but I don't think we 
have agreement on what the <issued> element should contain.

> 8) any subjective publication date the author may wish to associate 
Is it the first #4, and cannot change?  Is it the last #4?  Is it #8?  
It COULD be any of them.  Let's decide which of those is/are useful and 
decide on an element to put it/them in.

>  As an aggregator author, I am only interested in one, maybe 2 dates:
> 1) The date I would have first found the entry had I been checking 
> once a minute
>> first, last, or first and last of each.
The first #4.

> 2) A date to show the user, usually the same as above
Under what circumstances would you want to show a different date?  
Which date would that be?

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Mon, 12 Jul 2004 23:35:31 +0200

> 2) A date to show the user, usually the same as above

What a view date is, is by it's very nature not in a feed author's control  
[2]. You might be interested in the modified date. Your neighbour in the  
issued date. Your friends could want the issued date in UTC, I could want  
all three of the dates in +01:00 or +02:00 depending on time of year.   
Your boss could want the delta between created and issued, but only when  
written within your working hours.

___
[1] Those with a view differing from mine could read this as first-issued)
[2] A real example: Opera's aggregator/mail program by default displays  
"Monday 13:32:25" for entries from the current week, when that entry is  
 from the previous day or before.

-- 
Arve Bersvendsen

---

From: Antone Roundy <[email-masked]>
Date: Mon, 12 Jul 2004 16:06:40 -0600

On Monday, July 12, 2004, at 03:35  PM, Arve Bersvendsen wrote:
> What a view date is, is by it's very nature not in a feed author's 
> control [2]. You might be interested in the modified date. Your 
> neighbour in the issued date. Your friends could want the issued date 
> in UTC, I could want all three of the dates in +01:00 or +02:00 
> depending on time of year.  Your boss could want the delta between 
> created and issued, but only when written within your working hours.

Yes, the way the dates are formatted for display is up to the user.  
The question for us in defining the format is which data needs to be in 
the feed in order for the user to be able to get their software to 
display what they want?  All but the boss's desired information could 
be covered by having the issued date in the author's local time (I 
presume that's what you mean by what your neighbour wants?) and the 
modified date (in which timezone?)  Your client software can convert 
the dates UTC if desired, so it doesn't need to be stored separately 
that way.  (BTW, as long as either of the two dates indicates the 
origin timezone, the other COULD be in UTC).

As for your boss wanting to know how long it took you to write and 
publish the entry, that probably doesn't need to be in the feed--your 
boss should be able to find that out from data stored in your 
publishing system.  I don't think this is going to be of general 
interest to readers of the feed.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 12 Jul 2004 16:25:33 -0600

On Monday, July 12, 2004, at 04:06  PM, Antone Roundy wrote:
> The question for us in defining the format is which data needs to be 
> in the feed in order for the user to be able to get their software to 

Oops, I abandoned my own rigor here.  Additional questions:

1) By "issued date" and "modified date" do you mean objective 
timestamps, or author-specifiable (subjective) timestamps? (2, 3, 4 or 
6, 7, 8)

2) By "issued" do you mean first issued or most recently issued (if the 
same entry was "issued" more than once)?  (first 4 or 8 or last 4 or 8)

3) By "modified", do you mean the last major change which changed or 
non-trivially augmented the meaning of the entry, or the last 
modification of any kind, including things like spelling fixes? (2|6 or 
3|7)

Yeah, it may be difficult to draw a perfect line between major and 
minor changes, but a lot of people, myself included, seem to WANT to be 
able to differentiate, and I for one would prefer the publisher's best 
effort to do so over not having any hope of differentiating.

---

From: "Roger B." <[email-masked]>
Date: Mon, 12 Jul 2004 17:49:50 -0500

>       improve the quality of service or data in the syndication sphere.

RE: 1 and 2... Only? No. Primarily? Yes. From the roadmap on down, blogging
has been the basis of Atom's existence.

RE: 3... Repeatedly claiming that something is bad practice does not make it
bad practice. Modified dates change. Publish dates change. That's the way it
is.

> This would take me less than two minutes to implement in my tool.

Uh oh. Once we've reached the point where we're violating the programmers'
corollary to Godwin's Law, it's probably time to move on.

---

From: Walter Underwood <[email-masked]>
Date: Mon, 12 Jul 2004 16:17:55 -0700

--On Monday, July 12, 2004 11:35 PM +0200 Arve Bersvendsen <[email-masked]> wrote:
> control [2].

It is in the author's control if we allow the author to provide
a display date. When an author is posting at 3am local time, or
during Ramadan, the author's view of the date matters, and should
normally be preferred.

This is different from the normal localization approach, were all
dates are converted to local format.

wunder

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Tue, 13 Jul 2004 02:41:10 +0200

> during Ramadan, the author's view of the date matters, and should

No. A reader might reformat this date anyway she/he/it pleases, no matter  
what the author's preferenced display format is. That however does not  
mean that we should prevent the author from providing a default date  
preference, based on location, religion and culture. That information is  
however, in my view, best kept out of the date element;

<entry>
   ...
   <author>
     <name>James T. Kirk</name>
     <timezone>-00:00</timezone>
     <calendar type="x-stardates" />
   </author>
   <title>Personal Log Entry</title>
   <created>2287-12-25T13:33:37Z</created>
   <modified>2287-12-25T15:42:22Z</modified>
   <issued>2287-12-25T16:00:00Z</issued>
   ...
</entry>

-- 
Arve Bersvendsen

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Tue, 13 Jul 2004 02:44:22 +0200

> timestamps, or author-specifiable (subjective) timestamps? (2, 3, 4 or  

Objective. Modified would/should normally be generated by the author's CMS.

The user needs to be able to set atom:issued, if any CMS should be able to  
schedule publishing in the future. If the interface between the author and  
the CMS allows for "subjective" dates, that is fine by me. If you want to  
provide, "Noon, tomorrow" or "midnight, monday in two weeks" as "issued",  
that's a deal between you and your CMS. Externally, however, the date  
should be converted to an "objective" date, in the closest sense a  
user-provided can be.  Meaning: Convert it to a RFC3339 date.

Also: Keep in mind that any date can be wrong or falsified,  
machine-generated or not.

> same entry was "issued" more than once)?  (first 4 or 8 or last 4 or 8)

I firmly believe that "issued" should be set in stone. To me, it simply  
doesn't make sense that an entry issued three weeks ago suddenly gets this  
date changed. The entry is three weeks old. Period.

> modification of any kind, including things like spelling fixes? (2|6 or  

"Modified" = The last time this entry was touched/saved - no matter how  
small the change.

Note: the rest of this mail is only partly relevant to the date issue,  
feel free to modify subject when answering.

> Yeah, it may be difficult to draw a perfect line between major and minor  
> changes, but a lot of people, myself included, seem to WANT to be able  
> to differentiate, and I for one would prefer the publisher's best effort  
> to do so over not having any hope of differentiating.

I believe differentiating is best exposed externally through a different  
mechanism than messing around with dates. See PaceSuperesede for a  
starting point; <URL:http://www.intertwingly.net/wiki/pie/PaceSupersede>  
[1]

A major change, in my view, is a new entry, that supersedes a previous  
version. I just asked someone with experience from dead-tree publishing:

1. For a straight reprints, the ISBN doesn't change.
2. When a book is revisioned, the ISBN changes.
3. If the publisher changes, the ISBN changes.
4. If the cover changes, the ISBN changes.

I couldn't get an answer as to what happens to dates attached to these  
books.

If we relate Atom to dead-tree-publishing, could we make the following  
assumptions?

(0. The ISBN is (the closest) equivalent we have to entry:id)
1. This is equivalent to republishing in a different feed than the  
original. Nothing changes, including dates
2. This is a re-issue, with a new issued date, a new modification date, a  
new ID. In effect: a "new entry" that supersedes the former revision.
3. Same as for 2.
4. The title changes, which in effect makes this a new entry

___
[1] Supersede is a mechanism that has worked "sufficiently well" [2] for  
Usenet for many years. If there is a better mechanism, I'm open to  
suggestions.
[2] People have abused the mechanisms, hence the quotes.
-- 
Arve Bersvendsen

---

From: Graham <[email-masked]>
Date: Mon, 12 Jul 2004 21:10:15 -0400

> machine-generated or not.

Yes.

> I firmly believe that "issued" should be set in stone. To me, it 
> simply doesn't make sense that an entry issued three weeks ago 
> suddenly gets this date changed. The entry is three weeks old. Period.

This is a single entry that has been modified over time:

  http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus

What is its issued date? (NB Suggesting it be broken into multiple 
entries is not an option)

> 2. This is a re-issue, with a new issued date, a new modification 
> date, a new ID. In effect: a "new entry" that supersedes the former 
> revision.

The ID should never change, otherwise the element is useless (we might 
as well just generate a hash of the content) and we should forget it 
entirely, and Atom for that matter.

Graham

---

From: Sam Ruby <[email-masked]>
Date: Mon, 12 Jul 2004 22:58:58 -0400

> entries is not an option)

Based on the text and the URL, this page appears to have been originally 
created on 2004-02-17, issued on 2004-02-20, and last modified on 
2004-06-13.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Mon, 12 Jul 2004 23:21:01 -0400

On 12 Jul 2004, at 10:58 pm, Sam Ruby wrote:

> Based on the text and the URL, this page appears to have been 
> originally created on 2004-02-17, issued on 2004-02-20, and last 
> modified on 2004-06-13.

But that's useless to me. I can't sort by modified (Tim's is the only 
blog in the universe that is), and if I sort by issued, that post is 
going to be right at the bottom, even though Tim's written the 
equivalent of a new entry.

Try again.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 13:36:02 +1000

> entries is not an option)

+1 example

Note too that at the time of it's original publishing (IIRC) it was
explicitly stated that that entry will be updated often, and that that entry
is the canonical place to read all about GenxStatus.

Having permalinks is a good thing.

Can someone explain if PaceSupercedes expects the new-id entry to be
published at the superceded permalink? [1] Alternatively, will it (the
published permalink) be updated with a pointer to the superceding version,
(and that with a pointer when it too is superceded, and then that too again,
and again, and ...)?

e.

[1] effectively overwriting it, while leaving the original atom:entry
not-overwritten, if that makes any sense

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 13:56:04 +1000

> 4. If the cover changes, the ISBN changes.

What happens to the LOC or Dewey Decimal numbers in those situations?

Are ISBNs more like non-serial version identifiers? After all, when the vast
majority of users of books refer to "The Tao of Pooh" they don't say "the
publication with ISBN xxx". They say "The Tao of Pooh". The various editions
and revisions and covers are simply *versions* of the *same* thing. They are
not *different* things in the sense that "The Tao of Pooh" is different from
"100 things to do with a dead cat".

So far, blogs don't usually provide ongoing life support for previous
versions (something I expect to continue) ... it is only wikis that do so
(for their own reasons), and with them the page-id very usually stays the
same, providing access to previous versions with some additional linking
cruft.

e.

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Tue, 13 Jul 2004 11:12:07 +0200

> What happens to the LOC or Dewey Decimal numbers in those situations?

Dewey is a classification system, and, unless the subject of the book  
changes between the editions, a new revision of a book should be  
unaffected.

> Are ISBNs more like non-serial version identifiers?

ISBN does not identify version information. It identifies the  
country/language, publisher, and the [publisher's] item number.

Furthermore, the publisher number, is only an identifer for a block of  
item numbers which in turn is assigned to one publisher. When the  
publisher has used all of it's assigned item numbers, they are given a new  
publisher number.

For a quick intro on how ISBN works, look at Wikipedia's explanation,  
<URL:http://en.wikipedia.org/wiki/ISBN>.

> After all, when the vast majority of users of books refer to "The Tao of  
> Pooh" they don't say "the publication with ISBN xxx". They say "The Tao  
> of Pooh".

So do the vast majority of users when refering to blog entries; "Did you  
see Mark's hilarious entry on 'Pink numbers'?".  We only revert to using a  
unique identifers such as ISBNs when there is absolutely no other way to  
identify the entry.

- Did you see Mark's entry on 'Pink Numbers'?
  - Which Mark?  There are 3123153 Mark's
- Oh. Mark Pilgrim. At diveintomark.org
  - Which 'Pink Numbers' entry? He has 37 'Pink Numbers' entries.
- Oh, the one on May 30.
  - Ok. Thanks.

Only if there had been any more than three 'Pink numbers' stories on May  
30, people would have started asking for information precisely locating  
the entry, either in form of the permalink, or the ID.

> The various editions and revisions and covers are simply *versions* of  
> the *same* thing. They are not *different* things in the sense that "The  
> Tao of Pooh" is different from "100 things to do with a dead cat".

Yet, they have different unique identifiers. Humans use common sense when  
recognizing that "The Tao of Pooh, second edition" supersedes "The Tao of  
Pooh, first edition".

> versions (something I expect to continue) ...

I'd like to propose that we try to forget that Atom originated from blogs,  
bloggers and their needs for a moment.  While the early adopters of RSS  
mostly were bloggers, RSS is in very widespread use outside the  
blogosphere. So will Atom be. I'll

When we expand the context from 'Blogs', there are CMSes with revision  
control.

I'm also quite confident that there will be CMSes suitable for bloggers  
that lets the user revert to previous versions of an entry for further  
editing.

-- 
Arve Bersvendsen

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Tue, 13 Jul 2004 11:41:55 +0200

>> entries is not an option)

-0.5 example.  While I do agree with Sam's assessment of the dates, this  
example more shows the limitations of a particular publishing system than  
it shows the need to avoid (simple) revisioning support in Atom.

> Having permalinks is a good thing.

If permalinks really were permanent, we wouldn't really need entry:id.

> published permalink) be updated with a pointer to the superceding  
> version, (and that with a pointer when it too is superceded, and then  
> that too again, and again, and ...)?

This is a policy matter with the CMS in question. Possible solutions are:

1. The new revision (with it's new id), will continue to exist at the  
location of the previous entry. Pretty equivalent to the Genx example (if  
we assume that the Genx status page is "one entry"). An alternative access  
mechanism may be provided to access previous versions.
2. If the permalink changes, the previous version is updated with a  
pointer to the superseding version.
3. If the permalink changes, the CMS automatically uses HTTP redirects  
 from the previous version to the new version.

CMSes without any revisioning mechanisms would simply continue to work the  
way they always have, updating the modified timestamp.

Also note that, even if I co-authored PaceSupersede with Asbjørn Ulsberg,  
I think this particular line should be changed:

* atom:entry MAY contain an atom:supersedes element, but MUST NOT contain  
more than one.

Perhaps to:

* atom:entry MAY contain an atom:supersedes element, and MAY contain more  
than one. If several revisions of an atom:entry exists, there SHOULD be  
atom:supersedes referencing at least the initial revision and the last  
revision before the current.

(This is quite equivalent to having to keep a reference to at the very  
least both the top entry and last entry in a discussion thread, in case  
the last message in the threadgoes AWOL. Usenet newsreaders tries to  
preserve as much as possible in the References header)

-- 
Arve Bersvendsen

---

From: Graham <[email-masked]>
Date: Tue, 13 Jul 2004 06:53:01 -0400

On 13 Jul 2004, at 5:41 am, Arve Bersvendsen wrote:

> -0.5 example.  While I do agree with Sam's assessment of the dates,  
> this example more shows the limitations of a particular publishing  
> system than it shows the need to avoid (simple) revisioning support in  
> Atom.

Piss off. It's a real, perfectly valid blog entry on a popular blog  
that already has a syndication feed, and that I've already shown a  
simple example of how to support it properly within the elements we  
already have. It might be an extreme example, but what it represents is  
a valid general case (re-issuing) that we need to support.

> If permalinks really were permanent, we wouldn't really need entry:id.

If atom:id were permanent we wouldn't need this atom:supercedes  
nonsense.

(If anyone can't guess, -1,000,000 on PaceSupercedes. Stuff like it has  
been suggested before and has gone nowhere, as will this)

> * atom:entry MAY contain an atom:supersedes element, and MAY contain  
> more than one. If several revisions of an atom:entry exists, there  
> SHOULD be atom:supersedes referencing at least the initial revision  
> and the last revision before the current.

A reference to the initial version is important, isn't it? Why, if it  
didn't seem too obvious to work, I'd suggest we create an element that  
doesn't change through all revisions of the same entry [1] . No,  
scratch that, I'm being stupid.

[1]  
http://www.mnot.net/drafts/draft-nottingham-atom-format 
-02.html#rfc.section.4.13.5

Graham

---

From: Sam Ruby <[email-masked]>
Date: Tue, 13 Jul 2004 07:02:17 -0400

Graham wrote:

> But that's useless to me. I can't sort by modified 

Why not?

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Tue, 13 Jul 2004 07:20:52 -0400

>> But that's useless to me. I can't sort by modified

Read again what you deleted:
"I can't sort by modified (Tim's is the only blog in the universe that 
is)"

No other blog in the wild is sorted by the modified date of the 
entries. Entries stay in the order they were originally published. I 
need a date to sort on that works in the general case (which I've 
already demonstrated how to do).

Graham

---

From: Sam Ruby <[email-masked]>
Date: Tue, 13 Jul 2004 07:49:10 -0400

Graham wrote:

>> system than it shows the need to avoid (simple) revisioning support 
>> in  Atom.
> 
> Piss off. 

Please at least *TRY* to be civil.

> It's a real, perfectly valid blog entry on a popular blog  

You are also simultaneously maintaining that "(Tim's is the only blog in 
the universe that is)", which tends to argue against this being a 
representive sample that one should use to base decisions off of.

Let's proceed with the assumption for the moment that this is a 
representative sample.

max(date-on-page) = 2004-06-13
min(date-on-pate) = 2004-02-17

There also is a significant date which is reflected both in the URL and 
in a special sidebar "Around February 20, 2004".

These are three dates that appear significant.  What tags should be used 
for these?

Or, would you rather say that this example is not representative?

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Tue, 13 Jul 2004 09:42:30 -0400

> Please at least *TRY* to be civil.

That is me being civil. Saying the example isn't valid when it's from a 
real blog isn't in the slightest bit constructive.

> You are also simultaneously maintaining that "(Tim's is the only blog 
> in the universe that is)", which tends to argue against this being a 

That's one way to look at it. The other is that by considering this 
stuff properly and thinking about what people currently do you can end 
up with a much more flexible, meaningful model.

> There also is a significant date which is reflected both in the URL 
> and in a special sidebar "Around February 20, 2004".
>
> These are three dates that appear significant.  What tags should be 
> used for these?

You always ask this and it seems to serve no purpose other than to send 
the debate down a dead end.

Under PaceEntryDates:
  <created>2004-02-17</created>
  <modified>2004-06-12</modified>
  <issued>2004-06-12</issued>

Under the current draft: Not a clue.

The third date might fit neatly in a "subjective" date, or in 
first-issued if we have that, but I've no idea what its meaning was, so 
I'm only guessing.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Tue, 13 Jul 2004 08:02:30 -0600

> 8) any subjective publication date the author may wish to associate 

Let me see if I can get a sense of what we agree on and what we don't.  
Would I be correct to assume that we can all agree that:

A) to support legacy systems/data which have subjective dates, possibly 
without timezones, we have to support #8?

B) That A (#8) be REQUIRED?

C) that A (#8) be the only REQUIRED date construct (again, to support 
legacy systems & data)?

D) that A (#8) be the only subjective date?

E) that all Date constructs MUST specify a timezone, which MUST be 
-00:00 if it is unknown?

F) that the timezones MUST be numeric, except that either Z or +00:00 
MAY be used for UTC?

G) that all dates except A (#8) MUST be in UTC (Z or +00:00), unless 
unknown?

I've only heard one indirect, and uncommon, argument against my having 
omitted the creation date from my original proposed list. Does anyone 
have a use case for why that needs to be in the feed?

What we don't agree on, or consensus is unclear:

i) Can the issued/published date ever change?

ii) If it can, do we want to preserve a "first issued" date in the 
feed? (first #4)

iii) Do we want different Date Constructs for specifying major and 
minor changes, imperfect though the distinction may be? (last #2 and #3)

iv) If so, what if any guidelines do we want to provide for when to 
change each?

v) What assumptions do we want people to be able to make about omitted 
Date Constructs?  (This will be easier to answer after we've decided on 
which Date Constructs are going to exist).

vi) What do we want to call each of the Date Constructs?

Finally, my answers to the above questions:

i) Yes, as long as we track the first issued date.

ii) Yes.

iii) Yes.

iv) A major update alters or non-trivially expands the scope of the 
message. I minor update does not, and includes such things as spelling 
corrections and rewording for clarification of existing meaning.

v) If a major udpate date exists, but no minor update date exists, they 
are the same.  (Also, if both exist, the minor update must not be 
earlier than the major update).  If no update dates exist, but the 
objective issued date does, the update dates are the same as the issued 
date.  If only the subjective date exists, no other assumptions are 
possible.

vi) My heart is not set on anything in particular, but here's what 
comes to mind: subjective date: issued or published; first issued date, 
first-issued or first-published (can't think of an unambiguous single 
word); last major modification: modified; last minor modification: 
updated.

---

From: Sam Ruby <[email-masked]>
Date: Tue, 13 Jul 2004 10:24:31 -0400

> Under the current draft: Not a clue.

Note that there is some information loss there.  In this particular blog 
entry, it probably wasn't all that significant.  In other entries on 
Tim's blog, the nominal issue date can be very significant.

I've already stated what I think the answer would be given the current 
draft:

http://www.imc.org/atom-syntax/mail-archive/msg06805.html

> first-issued if we have that, but I've no idea what its meaning was, so 

If the next rev of the spec were clarified to indicate that "issued" 
means "first-issued", and should only change if the original "issued" 
date was recorded in error (and presumably, such a change would qualify 
as a substantial modification); and furthermore if "modified" were 
clarified to indicate that a change in this value indicates a "notable" 
modification; would these two changes suffice?

Graham, I think we are on the same side here.  We both don't want 
aggregator authors to have to guess anymore.  We want aggregator authors 
to have a clear and unambiguous answer to the question "why did (or did 
not) you sort this entry to the top of the list?" - the answer being 
"because the value of <foo> element did (or did not) change".

Trying to establish what we want to call "foo" is not a dead end. 
Neither my original take on this (last July) nor your take (in February) 
are the definitive last words on this subject.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Tue, 13 Jul 2004 13:51:47 -0400

On 13 Jul 2004, at 10:24 am, Sam Ruby wrote:

> Note that there is some information loss there.  In this particular 
> blog entry, it probably wasn't all that significant.  In other entries 
> on Tim's blog, the nominal issue date can be very significant.

There probably is room in the spec for a nominal date.

> if "modified" were clarified to indicate that a change in this value 
> indicates a "notable" modification; would these two changes suffice?

It's not about modification. My claim is that re-issuing an entry is a 
separate event from all modification. Creation and modification dates 
belong the document underneath the entry. Issuing and reissuing is 
about how the document is published as an entry, which is an 
independent thing.

> aggregator authors to have to guess anymore.  We want aggregator 
> authors to have a clear and unambiguous answer to the question "why 
> did (or did not) you sort this entry to the top of the list?" - the 
> answer being "because the value of <foo> element did (or did not) 
> change".

Yes. The interaction between aggregators and publishers needs to be a 
lot clearer than with RSS.

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 13 Jul 2004 20:57:09 +0200

On Mon, 12 Jul 2004 14:43:12 -0600, Antone Roundy <[email-masked]>  
wrote:

> The purpose of the list is merely to create a (hopefully)
> comprehensive list of POSSIBLE dates, where there's no ambiguity about
> what EXACTLY we mean when we refer to one of them

+1 to that purpose. I hope we can reach consensus on what we (and Dublin  
Core, for that matter) means with the different dates.

> For example, I think we have a pretty good idea of what the term
> "issued" means, but I don't think we have agreement on what the
> <issued> element should contain.

I definately do not think we have a pretty good idea. Or, people have a  
pretty good idea, but the idea is very different from person to person. It  
seems to be a common perception that 'issued' can be a subjective (and  
then, imho, informal) date. I disagree. DC says «Date of formal issuance  
(e.g., publication) of the resource», which I think outrules all  
«subjectiveness» to the date.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 13 Jul 2004 21:55:05 +0200

On Mon, 12 Jul 2004 16:25:33 -0600, Antone Roundy <[email-masked]>  
wrote:

> timestamps, or author-specifiable (subjective) timestamps?

Objective. Dublin Core uses the word «formal» which I find to be very far  
 from «subjective».

> same entry was "issued" more than once)?

If we would follow DC by the book, there is no past or present. It is only  
«now» which points to «this» item. The issued date is then when the item  
you're looking at was published. If you've made minor changes  
(typographical erratas) to the entry, that may (however uninteresting that  
is for most users and tools) change the 'modified' date. Major changes,  
which makes the entry worth reading again, should be done issuing a _new_  
entry which is related[1] to the previous one.

> non-trivially augmented the meaning of the entry

This should trigger a re-issuance of the entry, which would give it a new  
ID and a relation of «is version of» equal to the previous ID.

> to differentiate

Then Atom should be able to let you do so. Dublin Core defines this in the  
relation element, and I feel that Atom definately should adopt that term.

____
[1] <url: http://dublincore.org/documents/relation-element/>

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 13 Jul 2004 22:11:27 +0200

On Mon, 12 Jul 2004 16:17:55 -0700, Walter Underwood <[email-masked]>  
wrote:

> a display date.

Then that should be <userdate> and not <issued>, as «issued» in Dublin  
Core terms, is the formal date of issuance, not a subjective random string  
formatted as a W3CDTF.

> When an author is posting at 3am local time, or during Ramadan, the
> author's view of the date matters, and should normally be preferred.

Preferred by whom? Not by me, to be sure. And not by NRK. And not by EBU.  
We want dates we can trust, preferably provided by the tools issuing the  
entries. _All_ tools has this action. They just don't apply a date when  
doing it. The date provided by the user should not be <issued>, but  
<userdate>, <visible-date> or something in those lines.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 13 Jul 2004 22:25:44 +0200

On Tue, 13 Jul 2004 04:07:43 +1000, Eric Scheid  
<[email-masked]> wrote:

>> Up until the date discussion  surfaced just recently, I actually  
>> thought all Atom dates were objective.  I'm still amazed that's
>> not the case.
>

No, but I've just read up about him, and he's hardly a use case for Atom.  
At least nothing within the 80/20 rule. Either way, in his case, <issued>  
should be set to when the diary «entries» were issued to its intended  
audience. For the introduction[1], for example, <issued> should be set to  
'1893-MM-dd', if it's not changed considerably.

If it is, the original should be placed untouched somewhere, and the  
current introduction[1] should be related[2] to it as a «version of» the  
original.

____
[1] <url: http://www.pepysdiary.com/intro/pepys/>
[2] <url: http://dublincore.org/documents/relation-element/>

---

From: Antone Roundy <[email-masked]>
Date: Tue, 13 Jul 2004 15:01:54 -0600

On Tuesday, July 13, 2004, at 01:55  PM, Asbjørn Ulsberg wrote:
> On Mon, 12 Jul 2004 16:25:33 -0600, Antone Roundy 
> <[email-masked]> wrote:
> ... Dublin Core uses the word ....
> ...
> If we would follow DC by the book
> ...
> ...Dublin Core defines this in the relation[1] element, and I feel 
> that Atom definately should adopt that term.
> ____
Okay, one more big question (which I think we should revisit a little 
later--see below)--do we want to:
1) adopt Dublin Core elements exclusively (by which I DON'T mean using 
their namespace--just defining the dates in our namespace identically 
to the way they do it)?
2) use a mix of DC and our own elements?
3) make up our own elements which may have the same names as DC dates, 
but possibly different meanings?
4) make up our own elements, being sure that they don't duplicate DC 
element names to avoid confusion?

My answers:
1) If we can find a set of DC dates that meet our needs, and which 
won't cause confusion by having non-intuitive names, fine--I'm not 
familiar enough with DC to comment further on that right now.
2) Once again, if we end up with something that meets our needs, fine.
3) I don't have a problem with this, but I can imagine some others 
would.
4) I hope we can avoid doing this.

...but before we get to the issue of nailing down the names of the Date 
Constructs, why don't we decide what Date Constructs we want (ignoring 
the fact that the names we temporarily refer to them by might be the 
same as DC dates with different meanings).  Once that's done, if 
there's a direct mapping to DC dates which doesn't lose the meaning 
that we decide we want, fine. I do not think it's a good idea to 
squeeze Atom into Dublin Core's set of dates if doing so keeps us from 
being able to express the dates that would serve Atom best.

> 8) any subjective publication date the author may wish to associate 

can we agree that we need #8, regardless of everything else?

As for the rest, I'm guessing that the following alternative points of 
view capture most everyone's position:

A) We need #4, which can not change, and the last #3.  If #2 occurred, 
a new entry should be created with some means of indicating that it had 
replaced the original entry.

B) We need #4, which can not change, and the last #2/#3--don't 
differentiate between them.

C) We need the last #4 (it can change), the last #2, and the last #3. 
[this is my POV]

D) We need the last #4 (it can change), and the last #2/#3--don't 
differentiate between them.

Comments?  Opinions?

---

From: Norman Walsh <[email-masked]>
Date: Tue, 13 Jul 2004 17:06:36 -0400

/ Asbjørn Ulsberg <[email-masked]> was heard to say:
| date. Major changes,  which makes the entry worth reading again,
| should be done issuing a _new_  entry which is related[1] to the
| previous one.

FWIW, I'm convinced. I haven't done it often, but the ability to "reissue"
was really the only thing that made me want the created/issued/modified
triumvirate.

Created = when I created the essay.
Issued = when I last made "significant" changes to the entry.
Modified = when I last changed any of the bits in the entry.

I'm now convinced that it would be better to use just two:

Issued = when I published the essay
Modified = when I last changed any of the bits in the entry.

If I make a "significant" change, I should

1. Create a new entry with a new ID and new dates
2. Indicate that this new entry dcterms:replaces the original.
2. Update the original to say it's been dcterms:isReplacedBy the new one.

It's more work, but it'll make for a better historical record.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Simplicity is always a virtue.--Edward
http://nwalsh.com/            | Abbey

---

From: Sam Ruby <[email-masked]>
Date: Tue, 13 Jul 2004 17:49:58 -0400

> It's more work, but it'll make for a better historical record.

It's not much more work for you, but it is much more work for consumers.

Consider that a typical aggregator polls for data.  If you replace an 
entry twice, and the aggregator missed the first one, then it has an 
incomplete history to reconcile.

- Sam Ruby

---

From: "Jeremy Gray" <[email-masked]>
Date: Tue, 13 Jul 2004 14:47:29 -0700

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]] On Behalf Of Norman Walsh
> Sent: Tuesday, July 13, 2004 2:07 PM
> To: Atom Syntax
> Subject: Re: a methodical approach to defining what date elements we need
> 
> 
> FWIW, I'm convinced. I haven't done it often, but the ability to
> "reissue" was really the only thing that made me want the created/
> issued/modified triumvirate.
> 

+1

I've been trying my hardest to just sit back and watch this thread unfold
but I think that Norm hits this one on the head so well that its time to
chime in with my +1.

Issued is objective, gets set once, and never changes.

Modified is objective, gets set initially, and can be updated when minor
changes are made.

Major changes are handled by issuance of a new entry with pointers back from
the new and forth from the old. This has the benefit of recording the full
chain of changes (and retaining the content of each entry version thereof,
allowing for diffs and such) while avoiding the slippery slope that is
first-issued, last-issued, third-issued,
second-to-last-tweak-before-bedtime-issued, etc.) and the data loss of
issued+.

Add in a purely subjective element that authors can use for things like
"After partying late last night" and we're good to go.

Now, who wants to take a stab at a normative definition, if one is even
possible, of a minor change (modification) vs. a major change (requiring new
issuance)? :)

Jeremy Gray

---

From: Robert Sayre <[email-masked]>
Date: Tue, 13 Jul 2004 18:09:02 -0400

> incomplete history to reconcile.

But if he just tweaks a date field each update, the consumer won't even know
it missed anything.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Tue, 13 Jul 2004 16:22:21 -0600

> incomplete history to reconcile.
This, and the fact that people ARE going to republish heavily modified 
entries without creating a new one are my big reasons for not favoring 
any kind of "replaces" system.  I'd prefer a modified (big 
change)/updated (small change) combo, which hopefully would be simple 
enough to create a UI for (like someone suggested, default to small 
change and have a checkbox to indicate a big change), and if so, would 
encourage people to differentiate between little fixes and big changes.

On the other hand, that same UI could control whether an entry is 
updated or replaced (though it's greater complexity might result in 
some developers not supporting it).

Anyway, to me, the benefit just doesn't outweigh the much greater 
complexity for the consumer.

---

From: "Jeremy Gray" <[email-masked]>
Date: Tue, 13 Jul 2004 15:28:26 -0700

> From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Ruby
> Sent: Tuesday, July 13, 2004 2:50 PM
> To: Norman Walsh
> Cc: Atom Syntax

-snip-

> incomplete history to reconcile.

Worst case: the aggregator thinks it is an entirely new post.
Middle case: the aggregator notices that there is a pointer to a previous
version and visibly notifies the user that the entry is replacing one it
does not have on hand.
Best case: the aggregator notices the pointer and uses some
yet-to-be-defined mechanism to talk to the server to get the missing entry.

Even the worst case doesn't appear to be particularly problematic. Is there
something I'm missing?

Jeremy Gray

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 00:38:28 +0200

> incomplete history to reconcile.

It's a good use case, but the aggregator would still have the «hole» if  
the entry was re-issued by just changing 'issue'. The only difference is  
that one now has an option to view all of the changes independantly.

This way of relating re-issues of entries would be best to have work in a  
very similar way to threading. E.g. if the threading-mechanism is based on  
one single element pointing to one single ID, you'd still have the «hole»  
problem, which needs some solution.

One named solution is to define a URN resolution mechanism for atom:id,  
almost like MessageID for USENET on Google. Pubsub or Feedster could, for  
example, be two atom:id resolution hosts. If you're missing an atom:id  
 from your aggregator, ask if Pubsub or Feedster has it.

---

From: "Jeremy Gray" <[email-masked]>
Date: Tue, 13 Jul 2004 15:54:26 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Asbjørn Ulsberg
Sent: Tuesday, July 13, 2004 3:38 PM
To: Sam Ruby; Norman Walsh
Cc: Atom Syntax
Subject: Re: a methodical approach to defining what date elements we need

-snip-

+1

This would match up nicely with my previous post, turning "Middle case"s
into "Best case"s.

Jeremy Gray

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 01:02:00 +0200

On Tue, 13 Jul 2004 16:22:21 -0600, Antone Roundy <[email-masked]>  
wrote:

> any kind of "replaces" system.

Sam's problematic use case is just as problematic now as with any  
«supersede» system. An entry might be lost in void no matter what we do.  
The only solution to this is to be able to fetch the entry on a public  
repository, like Google perhaps. USENET's MessageID's already work like  
this. Perhaps atom:id could too.

> I'd prefer a modified (big change)/updated (small change) combo

What about keeping the semantics of 'modified' as is, and add a simple  
solution to the 're-issued' cases, if people are having difficulties with  
accepting <relation>; Allow for several <issued> elements. I would  
definately prefer a <relation>[1]-mechanism over mulitple <issued>  
elements, but it's a good compromise, and <relation> might still be  
supported on top of that <issued> semantic.

What the different <issued> elements would mean, is however not very  
clear. I'm not sure we can do or say anything but «If you re-issue an  
entry, you SHOULD (or MUST) append a new atom:issued element to atom:entry  
that reflects the new issue date. The original atom:issied should be left  
intact». The order of the <issued> element is of no significance; they  
could easilly be ordered chronologically with a string sort (if they are  
in the same timezone).

So, simple solution: multiple <issued> elements. A bit more complicated  
solution: <relation>. The bonus with adding <relation> is, though, that we  
get «for free» all the other attributes of the element, which obsoletes  
current @rel="alternate" with much more explicit attributes; 'IsFormatOf'  
(when an entry is an alternative representation for an HTML article),  
'References' (threading) and 'IsBasedOn' (translations of an entry).

____

---

From: Norman Walsh <[email-masked]>
Date: Tue, 13 Jul 2004 19:18:26 -0400

/ Sam Ruby <[email-masked]> was heard to say:
| Norman Walsh wrote:
|
|> I'm now convinced that it would be better to use just two:
|> Issued = when I published the essay
|> Modified = when I last changed any of the bits in the entry.
|> If I make a "significant" change, I should
|> 1. Create a new entry with a new ID and new dates
|> 2. Indicate that this new entry dcterms:replaces the original.
|> 2. Update the original to say it's been dcterms:isReplacedBy the new one.
|> It's more work, but it'll make for a better historical record.
|
| It's not much more work for you, but it is much more work for consumers.
|
| Consider that a typical aggregator polls for data.  If you replace an
| entry twice, and the aggregator missed the first one, then it has an
| incomplete history to reconcile.

But my plan is *never* to replace an entry.

I write essay A. It goes out in the feed.

I write essay B, and update essay A. They both go in the feed and B
says it replaces A and the modified A says it's replaced by B.

I write essay C, that replaces B. Now, if you missed B somehow (how,
it's in the feed along with C that you just got?), C still points to B
which points to A.

Or did you mean something else?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Sometimes in life situations develop
http://nwalsh.com/            | that only the half-crazy can get out
                              | of.--La Rochefoucauld

---

From: Sam Ruby <[email-masked]>
Date: Tue, 13 Jul 2004 19:46:18 -0400

> Or did you mean something else?

Best explained by example.  Consider:

   "B"    = http://norman.walsh.name/2003/02/stthomas
   "feed" = http://norman.walsh.name/atom/whatsnew.xml

Clearly entries are being purged from feeds at some point.

If one fetches a feed intermittently, there can be gaps in history, 
resulting in an inability to reconcile history.

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Wed, 14 Jul 2004 10:19:20 +1000

On 14/7/04 9:02 AM, "Asbjørn Ulsberg" <[email-masked]> wrote:

> So, simple solution: multiple <issued> elements

+1

---

From: Graham <[email-masked]>
Date: Tue, 13 Jul 2004 23:51:17 -0400

> But if he just tweaks a date field each update, the consumer won't 

I think you misunderstand. An aggregator downloads and caches entry A. 
While the user is offline, A is superceded by B and then B is 
superceded by C. The user goes back online and downloads C, which says 
it supercedes B, which the aggregator has never seen. The aggregator 
therefore has no way of knowing and/or conveying to the user that C is 
a later version of A. This is hardly an edge case or a contrived 
scenario.

Compare this with having atom:id be static for all versions of the same 
entry, and the problem never comes up. For the supercedes approach to 
match this robustness, you must either:
a) Include the ids of all previous revisions in every entry (which 
won't scale)
b) Include the id of the original entry in all revisions (which, if you 
swap some element names, is exactly the same as keeping the id static)

If you want to add version ids to atom, I'd be happy for you. Just make 
sure atom:id never changes.

Graham

---

From: "meyer_jon" <[email-masked]>
Date: Wed, 14 Jul 2004 01:18:42 -0400

>> for display.  For human consumption.

If people want "qualitative subjective" dates for display, use xsd:string,
remove any specification of how the date is formatted, and be done with it.
Then I can be free to use my favorite human-oriented date approach, e.g.
"environ deux heures après café, Dimanche, mi juin”.

In my opinion, this kind of qualitative subjective information fits very
nicely as part of the content of a blog entry, but if people want an
optional "atom:issued-subjective" element that's ok by me. Lets keep
atom:issued, atom:modified and atom:created as xsd:dateTimes though, with
timezones or UCT. 

Locality is useful data. I would be in favor of an atom:location tag as part
of atom:person tag, so I can say something like:
 
<author>
   <name>John Doe</name>
   <location>US-NY</location>
</author>

Not sure if there is a good standard to use for locations however.

Jon

@issued-subjective="at 1am, sorry if I'm a bit grouchy"

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 13 Jul 2004 22:44:06 -0700 (PDT)

> It's more work, but it'll make for a better

Why is this better? As an aggregator author I
definitely wouldn't want to support this convoluted
process. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Sam Ruby <[email-masked]>
Date: Wed, 14 Jul 2004 06:20:57 -0400

Graham wrote:

> belong the document underneath the entry. Issuing and reissuing is about 
> how the document is published as an entry, which is an independent thing.
> 

OK, it seems to me that we are making progress, slow progress, but 
progress.  Let me see if I can recap.  What I want to do is describe 
this in terms that can't be confused with terms that are encumbered and 
loaded with previous associations, like issued.

== == == == == == ==

Date 1: Updated

This date is meant to be a machine generated timestamp indicating when 
the most recent substantive change has been made to the entry.

One should be able to depend on this field for sorting purposes, and to 
depend on it to identify if the current version of this content of this 
entry has been (substantially) seen before.

In theory, this field can be updated independent of the content, but in 
practice that is rarely done.  Updating the content without updating 
this field would be with the intent of not drawing attention a change 
that was made.

While time zone information may be present on this field, it is not of 
any primary importance.

  = = =

Date 2: Display

This date is effectively a user entered date.  It means whatever the 
user wants it to mean.  It can be fictitious, it can be in the future. 
It can even be fanciful (Samuel Pepsys comes to mind).

This date is effectively part of the content.  Accordingly, if the 
display timestamp changes, the updated timestamp should also change.

We could define it as a string, but an ability to internationalize and 
search on this field is desirable.  One would rarely sort on this field. 
  Having an ability to express perceived relative local time in this 
field is also desirable.

  = = =

Date 3: Created

Another machine generated timestamp, indicating when the entry was first 
created.

This field is not intended for significantly used by an aggregator.  It 
came into being simply because the first three blog vendors I happened 
to talk to identified this as a common piece of information that they 
all track.  If it truly turns out to be a relatively common concept, 
then assigning it a common name is desirable from a tool migration point 
of view.

If, on the other hand, this field does not survive the standardization 
process, then so be it.

== == == == == == ==

Separate from all this is the ability of multiple entries to be related. 
  One certainly can create new entries which were based on another 
entry.  Capturing this relationship in the format is a desirable thing.

A few things to note, however.  Such new entries are separate and 
distinct from the original.  They would have new ids.  When displaying 
items from a feed, one would expect to see both the original and new 
items separately listed.  The original could continue to be updated 
independently after the new item was created.

  - Sam Ruby

---

From: Norman Walsh <[email-masked]>
Date: Wed, 14 Jul 2004 07:16:42 -0400

/ Sam Ruby <[email-masked]> was heard to say:
[...]
| Best explained by example.  Consider:
|
|    "B"    = http://norman.walsh.name/2003/02/stthomas
|    "feed" = http://norman.walsh.name/atom/whatsnew.xml
|
| Clearly entries are being purged from feeds at some point.

Indeed. The most recent 30, IIRC.

| If one fetches a feed intermittently, there can be gaps in history,
| resulting in an inability to reconcile history.

If you watch the feed intermittently, you could have lots of gaps.
It's not impossible to reconcile however, because you have a pointer
to the essay that's been replaced.

Anyway, as I said in response to Dare, I don't expect aggregators to
do anything special with this information (I don't mind if they do,
though). The essays are distinct and just happen to carry metadata
that says they're related.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | When we are tired, we are attacked by
http://nwalsh.com/            | ideas we conquered long ago.-- Nietzsche

---

From: Norman Walsh <[email-masked]>
Date: Wed, 14 Jul 2004 07:14:20 -0400

/ Dare Obasanjo <[email-masked]> was heard to say:
| --- Norman Walsh <[email-masked]> wrote:
|> 
|> I'm now convinced that it would be better to use
|> just two:
|> 
|> Issued = when I published the essay
|> Modified = when I last changed any of the bits in
|> the entry.
|> 
|> If I make a "significant" change, I should
|> 
|> 1. Create a new entry with a new ID and new dates
|> 2. Indicate that this new entry dcterms:replaces the
|> original.
|> 2. Update the original to say it's been
|> dcterms:isReplacedBy the new one.
|> 
|> It's more work, but it'll make for a better
|> historical record.
|
| Why is this better?

I think it's better because the original essay isn't lost.
Readers can find the original as well as the revised version.

| As an aggregator author I
| definitely wouldn't want to support this convoluted
| process. 

I'm not suggesting aggregators should do anything special. There are
two essays, they go in feeds and get aggregated. They happen to carry
with them some metadata that describes that they're related. I don't
care if the aggregator displays that or not. Might be nice if they
did, but it's hardly something you'd have to spend a lot of time
writing code to support.

But apparently my comments on this thread aren't going to help achieve
consensus so I'll stop, mostly. I certainly won't press the issue if
some other consensus arises.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | When dealing with the insane, the best
http://nwalsh.com/            | method is to pretend to be
                              | sane.--Hermann Hesse

---

From: "Roger B." <[email-masked]>
Date: Wed, 14 Jul 2004 08:53:43 -0500

> the most recent substantive change has been made to the entry.

Sam: +1, if we agree that "substantive" is to be defined by the publisher.

> user wants it to mean. ... One would rarely sort on this field.

 +0.5. I don't think "rarely" fits the bill here.

If the chronology of entries matter, the display date is all you can rely
upon. When I'm telling the one-entry-per-day story of my vacation, it
doesn't matter how many times I modify each entry, or how *much* I modify
them, or that I modified them at all... my readers will expect those entries
to show up in their aggregators in the order defined by the Display date.
The story makes no sense otherwise... it becomes a jumbled mess. 

The exception would be newspaper-style aggregators that throw multiple feeds
into a single pile. In that case, both Updated and Display are irrelevant to
the default sort, since such apps generally want to push anything new to the
top, regardless of what the publisher has to say.

None of which is meant to suggest that some people won't sort on Updated,
but Display is the more viable default.

> Another machine generated timestamp, indicating when the entry was first

+1 with no caveats.

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 14 Jul 2004 07:05:08 -0700 (PDT)

--- Sam Ruby <[email-masked]> wrote:
> progress.  

Agreed. 
 
> the most recent substantive change has been made to

+ 1

> It can even be fanciful (Samuel Pepsys comes to

-1 

I don't see what purpose this date serves. This is a
potentially bogus date that potentially will confuse
producers and consumers of Atom feeds. 
 
> then assigning it a common name is desirable from a

I don't see why this date should be in the feed. I can
understand having a concept such as issued but since
it seems tools don't seem to track that very well I
don't see why we should settle for a date field that
is primarily of use only to the content producer not
content consumers. 

=====

---

From: Tim Bray <[email-masked]>
Date: Wed, 14 Jul 2004 07:22:04 -0700

On Jul 14, 2004, at 3:20 AM, Sam Ruby wrote:

> this in terms that can't be confused with terms that are encumbered 
> and loaded with previous associations, like issued.

Near as I can tell, Sam's proposal covers all the use-cases I've seen 
out there in the syndication space, I'm generally +1 on the whole 
thing.

It would be nice if a couple of the heavy implementors were to have a 
close look. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Wed, 14 Jul 2004 10:39:11 -0400

> producers and consumers of Atom feeds. 

I'm going to assume for the moment that the problem is my lack of 
ability to express the concept clearly.  But my premise is that you are 
already seeing those types of dates, you simply may not know realize it 
by virtue of the fact that they are improperly or poorly tagged.

Let me be clear: I am not trying to break new ground here.  I am merely 
trying to categorize what I already see out in the field.  So, if you 
will bear with me, let's take a look at the following together:

http://www.livejournal.com/update.bml?mode=full
http://help.blogger.com/bin/answer.py?answer=139&topic=17
http://www.movabletype.org/features.shtml
http://journurl.com/?entry=1007&template=upgrade

In the latter two look for text like and "Movable Type allows you to set 
a post's date stamp to any date or time you wish, for pre-dating or 
post-dating information when it goes live.", and "Pre- and post-date 
entries"

 From this sample, I gather that there is an existing need, it already 
is widely deployed across a number of tools, and presumably has already 
bled into a wide number of feeds that you already have been consuming.

If we deny this information a home, it will simply find one of its own 
accord.

So, how do we capture the concept of a user entered date that means 
whatever the user intends it to mean?

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 14 Jul 2004 07:56:37 -0700 (PDT)

--- Sam Ruby <[email-masked]> wrote:
> So, if you 
> If we deny this information a home, it will simply

I would categorize the features described at those
links differently from how you described the date
field. It seems MovableType and other tools allow you
to control something that maps to the 'issued' date of
the entry. 

I sincerely doubt that any of these tool vendors would
want to make the distinction between issued and the
user entered date. I might be wrong so I'd love to get
their opinions. If I go with your descriptions, then
Atom needs 3 dates (last modified, created & bogus
user entered date). As an aggregator author I'd always
ignore the last one. 

=====

---

From: Antone Roundy <[email-masked]>
Date: Wed, 14 Jul 2004 08:59:20 -0600

Things the following list does not include:

1) A date of first issuance.  Having thought about it a little more, I 
don't see a particular need for it.  If you do, speak up.

2) A date of the most recent minor change (anything not reflected in 
Updated).  I'd like to see this in the format for the following reasons:

	a) The user should have the choice of having their feed reader flag 
minor changes as well as major.
	b) Similarly, software that republishes feeds might want to be aware 
of all minor changes so that it can update the data it is publishing 
when changes are made. Depending on the process, it may be able to 
simply overwrite old data, even if not changed. But if the process of 
replacing old data is laborious (for example, pushing updates out to 
multiple clients), being able to determine when minor updates have been 
made becomes important.
	c) Finally, the point without which a) and b) wouldn't matter 
much--detecting minor changes will be much simpler if it only requires 
checking a date stamp than if the feed reader has to compare all of the 
data in the entry to what it has cached.

One could certainly get by without it, but I'd like to have that date 
stamp in the format.

On Wednesday, July 14, 2004, at 04:20  AM, Sam Ruby wrote:
> One should be able to depend on this field for sorting purposes, and 
> to depend on it to identify if the current version of this content of 
> this entry has been (substantially) seen before.
>
> In theory, this field can be updated independent of the content, but 
> in practice that is rarely done.  Updating the content without 
> updating this field would be with the intent of not drawing attention 
> a change that was made.

+1.  As was pointed out to me (off list, I think), I had "updated" and 
"modified" backwards.  I agree with this usage of "updated".

> While time zone information may be present on this field, it is not of 

-1.  I don't see any reason not to require timezone info in all dates, 
as long as -00:00 (unknown) is allowed.

> display timestamp changes, the updated timestamp should also change.

+1.

> search on this field is desirable.  One would rarely sort on this 
> field.  Having an ability to express perceived relative local time in 
> this field is also desirable.

-1 on defining it as a string.  If someone wants to indicate "Written 
during Ramadan" or something, I'd think that would belong with the rest 
of the content in <content>.  Needing a date field for free-form 
expressions feels like an edge case to me.

> Date 3: Created
>
> Another machine generated timestamp, indicating when the entry was 
> first created.
>
> This field is not intended for significantly used by an aggregator.  
> It came into being simply because the first three blog vendors I 
> happened to talk to identified this as a common piece of information 
> that they all track.  If it truly turns out to be a relatively common 
> concept, then assigning it a common name is desirable from a tool 
> migration point of view.
>

+1  I certainly have no objection to having a creation date in the 
format, but I don't see it being of much use except for things like 
tool migration.  That's enough reason to allow it.  Certainly don't 
require it.

> Separate from all this is the ability of multiple entries to be 
> related.  One certainly can create new entries which were based on 
> another entry.  Capturing this relationship in the format is a 
> desirable thing.
>

+1 -- as long as people are free to make substantial modifications (and 
signal them through a date change) without being required to call it a 
new entry--as it would be with the above definition of "updated", then 
yes, this is desirable.

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 14 Jul 2004 08:31:53 -0700 (PDT)

> Updated).  I'd like to see this in the format for

What is the difference between a minor change and a
major change? Are publishing tools now supposed to
have heuristics that detect when the user fixes a typo
versus adds two new paragraghs to a post? Is the user
supposed to make this distinction themselves? 

What tool vendor has asked for this functionality or
has claimed this functionality makes their job easier? 

=====

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Graham <[email-masked]>
Date: Wed, 14 Jul 2004 11:50:01 -0400

> this entry has been (substantially) seen before.

You word this as if you want all publishers to update the field when 
they make substantive changes, and that not updating the field means 
the changes aren't important. Is that correct?

> this field is also desirable.

-1 to string - I want to be able to reformat it.

> independently after the new item was created.

So when there's a 1:1 relationship, we use the same id? Fantastic.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Wed, 14 Jul 2004 09:54:30 -0600

>> the most recent substantive change has been made to

If the "updated" date is only updated for substantive changes, then the 
distinction already has to be made somehow.

> has claimed this functionality makes their job easier?
I don't know if anyone else has, but in the next version of one of my 
products, which is going to have this functionality, it would make it a 
lot easier for me.

---

From: "Roger B." <[email-masked]>
Date: Wed, 14 Jul 2004 11:18:39 -0500

> user entered date.

Dare: Correct... they're one and the same.

> If I go with your descriptions, then

There's nothing bogus about the user-defined date. It is *the* authoritative
date for an entry... ignoring it means that entries show up in the
aggregator out of order. Which may not be a problem for a particular type of
user or style of aggregator, but it's something to bear in mind.

OTOH, if you're currently respecting pubDate in RSS feeds, then you don't
even need to do anything new. Sam's display date == pubDate.

---

From: Tim Bray <[email-masked]>
Date: Wed, 14 Jul 2004 09:21:11 -0700

> supposed to make this distinction themselves?

+1.  This minor/major thing is an invitation to endless hairsplitting 
disputes.   As a consumer of a feed, I want the provider to know when 
they consider it to have been modified, as a binary condition.  As a 
provider of a feed, I don't want to have to invest cycles agonizing 
over how "major" an update is.  It's a binary decision: is it major 
enough for the change to be reflected in the feed, yes or no.  Without 
a shared definition of what major/minor *means*, this will produce zero 
interoperability. -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 14 Jul 2004 09:37:33 -0700 (PDT)

> distinction already has to be made somehow.

Can you back this up with a list of products and how
they differentiate substantive versus non-substantive
claims instead of speculation. If I have to implement
support for this functionality in RSS Bandit I'd like
some well defined and detailed description of what I'm
supposed to do as opposed to speculation based on
hearsay. 
 
> products, which is going to have this functionality,

What product? What functionality is made much easier
by having last-time-a-typo-was-fixed-date &
last-time-a-major-revision-of-text-was-made-date as
opposed to last-modified-date?

=====

---

From: Sam Ruby <[email-masked]>
Date: Wed, 14 Jul 2004 12:40:51 -0400

> as long as -00:00 (unknown) is allowed.

Just to be clear (and it is confusing, I was initially confused, and 
undoubtably many more became confused by reading what I initially wrote 
on the subject): -00:00 can not be used to express the concept that 
"lunch will be served at noon on Thursday".

A few things to help clarify this: the difference in time between 
2004-07-14T12:05:00-04:00 and 2004-07-14T16:00:00-00:00 is the same as 
the difference between 2004-07-14T12:05:00-04:00 and 
2004-07-14T16:00:00+00:00, namely 5 minutes.

It is not possible to compute the differences between 
2004-07-14T12:05:00 and 2004-07-14T12:00:00.

2004-07-14T12:00:00-04:00 means "noon, EDT"

2004-07-14T12:00:00+00:00 means "noon, UTC"

2004-07-14T12:00:00-00:00 means "the same point in time as noon, UTC, 
but in an undeclared timezone"

"-00:00" notation is apparently meant to convey the information that 
"this timestamp has been canonicalized to UTC".

- Sam Ruby

---

From: David Powell <[email-masked]>
Date: Wed, 14 Jul 2004 17:36:09 +0100

Quoting Sam Ruby <[email-masked]>:

I'm only going to comment on the choice of dates, not timezones anything else
that could take away from focus.

+1

This corresponds to something similar to the last instance of #2 in Antone’s
list.

I imagine it to be updated for anything more significant than correcting a typo
or formatting problem, such as adding an updated extra paragraph, but that is
up to the publisher of course.

I think that this can coexist with "supercedes" techniques (see the below)

This field would be optional.  We can't specify what is and isn’t a major
change, it depends on the publisher's usage.

+1

This corresponds to something similar to #8 in Antone's list.

If a blog was analogous to a paper diary, then this field would correspond to
the page that you write on.  Similar to VJOURNAL's DTSTART date [rfc2445
4.6.3].  Just a date that is associated with an entry.

Could be useful for interoperating with vCalendar agents?

This field should be optional.  It is only appropriate for journal type feeds,
but I think that that is a pretty major use case.

> search on this field is desirable.  One would rarely sort on this field. 

Please make this field machine readable.

> If, on the other hand, this field does not survive the standardization 

This corresponds to something similar to #1 on Antone's list.  One use of it is
to allow aggregators to sort entries by creation date, and then notify of
updates in a way other than displaying that item at the top of the list. 

I don't have any strong feelings about whether this should be required or not.

So we have dropped

#4 objective publishing date - This is pretty similar to either objective
creation date or objective major modification date isn't it?

#5 subjective creation date, #6 and #7 subjective modification dates - I think
that the only subjective date worth keeping is the display date.  I can do
without these.

#2 except for the last instance -  Keeping archived modification dates around
without anyway of obtaining the old copies seems pretty useless.  I imagine any
supercedes proposal will come up with something more useful, maybe involving
<link>

#3 objective minor modification stamp.

-1 to dropping this.

Pretty much every data object I can think of keeps a last modified stamp, from
HTTP resources, local files, database rows, vCards and vCalendars.  I think
that it is a mistake to remove this.  Last modified dates are necessary for
things like synchronization.  I think we only need keep the last modification
date though, not the whole history. 

This field should be required if the post has been modified in any way.

> entry.  Capturing this relationship in the format is a desirable thing.

Some people are suggesting that it is better to have a supercedes mechanism than
to qualify changes as minor or major.  Technically it may be better, but my
opinion is that a supercedes mechanism imposes a more complex workflow on
publishers than simply allowing them to change existing posts, so I would
prefer it if both "major updates" and "supercedes" were both allowed so that
the publisher can decide what is most suitable.

If people want supercedes instead, then they just don't use the "Updated"
field.

-- 
Dave

---

From: Sam Ruby <[email-masked]>
Date: Wed, 14 Jul 2004 12:53:40 -0400

> user entered date). As an aggregator author I'd always

What I described above is basically what I originally meant by the term 
issued.  People like Asbjørn and Graham have made separate but rather 
compelling cases that the term issued is probably not the most 
appropriate term to be used here.  I'm no longer attached to that term.

As to the label 'bogus', this clearly is something a number of major 
weblogging software vendors have chosen not only to implement, but to 
actively highlight in their features list.  Roger wants to sort on this 
field, Graham wants to reformat it (presumably for localization or 
usability purposes).

I am quite OK with RSSBandit swimming upstream on this issue.  Even if 
the only benefit of keeping this field separate is that there is a 
significantly reduced temptation for tool vendors to 'pollute' the set 
of date fields that RSSBandit actively cares about with information that 
the user carefully and deliberately chose to provide, then clearly this 
should be of significant value.

- Sam Ruby

---

From: Norman Walsh <[email-masked]>
Date: Wed, 14 Jul 2004 13:06:29 -0400

/ Tim Bray <[email-masked]> was heard to say:
| On Jul 14, 2004, at 8:31 AM, Dare Obasanjo wrote:
|
|>> 2) A date of the most recent minor change (anything
|>> not reflected in
|>> Updated).  I'd like to see this in the format for
|>> the following reasons:
|>
|> What is the difference between a minor change and a
|> major change? Are publishing tools now supposed to
|> have heuristics that detect when the user fixes a typo
|> versus adds two new paragraghs to a post? Is the user
|> supposed to make this distinction themselves?
|
| +1.  This minor/major thing is an invitation to endless hairsplitting
| disputes.   As a consumer of a feed, I want the provider to know when
| they consider it to have been modified, as a binary condition.  As a
| provider of a feed, I don't want to have to invest cycles agonizing
| over how "major" an update is.  It's a binary decision: is it major
| enough for the change to be reflected in the feed, yes or no.  Without
| a shared definition of what major/minor *means*, this will produce
| zero interoperability. -Tim

Are you saying that Atom entries need exactly one date: atom:modified?
Or two: atom:modified and atom:{issued|created}? I'm pretty sure
you're not in the three camp.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | For the mental patient's family and
http://nwalsh.com/            | society, mental illness is a 'problem';
                              | for the patient himself it is a
                              | 'solution'.--Thomas Szasz

---

From: Antone Roundy <[email-masked]>
Date: Wed, 14 Jul 2004 11:17:09 -0600

> supposed to do as opposed to speculation based on

No I don't have a list of products, but you yourself said "+1" to "a 
machine generated timestamp indicating when the most recent substantive 
change has been made to the entry."  Whatever process you would use to 
determine what is a substantive change is fine.  Any other modification 
to the data in the entry whatsoever would be considered non-substantive.

> opposed to last-modified-date?

CaRP Evolution's mySQL plugin.  
(http://www.geckotribe.com/rss/carp/plugins/mysql.php).  The current 
version does not make such a distinction.  The closest thing it does is 
to compare a subset of the fields in an entry to cached data for 
previous entries to determine whether the new entry is a duplicate or 
not.  Atom will have entry:id to handle that issue, but lacking a 
datestamp for the last minor modification, the same process will have 
to be employed in order to flag minor modifications, which is a feature 
I plan to implement.

---

From: Tim Bray <[email-masked]>
Date: Wed, 14 Jul 2004 10:46:59 -0700

> you're not in the three camp.

I'm with Sam, we need two.  One last-modified and one "what the user 
wants to appear here" to support this widely-used facility from 
LiveJournal and so on.  The canonical case would be a travel diary, the 
entry for July 1 may have been created on July 3 and modified on July 
8, but from the user's point of view it's still the entry for July 1.  
Frankly I don't see any interesting current or future use for "created" 
but I guess some do. -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 14 Jul 2004 10:48:07 -0700 (PDT)

--- Sam Ruby <[email-masked]> wrote:
> issued.  
> actively highlight in their features list.  

I disagree with your original description. You
described this date as some fanciful user entered date
that could potentially be meaningless. What
MovableType and co provide is a way for the user to
specify the issued date which is not the same as the
user being able to say "43rd day of the 31st month of
the millionth year" as the date. 

This still boils down to two relevant dates to me
issued (which defaults to the created date but the
user can override it) and last-modified. I'd like to
know why you think there should be three and also am
curious whether tools vendors like Roger agree with my
assessment. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: David Powell <[email-masked]>
Date: Wed, 14 Jul 2004 18:49:16 +0100

> major change?

You could do without "Updated" and just use "Modified" everywhere
instead, but I think that the user experience could be a lot better if
you had "Updated" too.

The difference has more to do with the implied effects I think:

"Modified" would be more like the Atom equivalent to HTTP's
Last-Modified header for entries. It tells software whether to process
an entry rather than ignore it. If Bloglines saw that an entry's
modified date had changed it would probably want to put the entry in
its database, but it wouldn't mark that entry as unread for its users.

You probably wouldn't display "Modified" to a user.

"Updated" would serve two purposes. It could be used for ordering, and
could be displayed at the bottom of the page, but also changing
"Updated" indicates a status change for the entry:

Setting "Updated" implies that the aggregator should indicate that a
change has occurred to the user. Maybe the entry would be marked
unread.

> Are publishing tools now supposed to

I think it is a difference in language in the UI.  A checkbox that
says edit this entry, vs republish this entry.

If Atom only had "Modified" to go by, then if a publisher decides to
add an extra field to their old entries, geo-location maybe, then the
readers of the feed would see all of their old posts marked unread,
which might be a bit annoying.

> has claimed this functionality makes their job easier?

Sorry can't help there.

-- 
Dave

---

From: Sam Ruby <[email-masked]>
Date: Wed, 14 Jul 2004 13:58:22 -0400

> curious whether tools vendors like Roger agree with my

You mentioned a date called "issued" (a name which remains problematic), 
"last-modified", and "created" (as the default for issued).  By my way 
of counting, that makes three.

I see the default for "issued" as being tool specific and therefore not 
normatively specified in the standard, particularly if the third date 
("created") is not present at all in the standard.

What I said about "created" is as follows[1]:

     This field is not intended for significantly[sic] used by an
     aggregator. It came into being simply because the first three blog
     vendors I happened to talk to identified this as a common piece of
     information that they all track. If it truly turns out to be a
     relatively common concept, then assigning it a common name is
     desirable from a tool migration point of view.

     If, on the other hand, this field does not survive the
     standardization process, then so be it.

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg06946.html

---

From: Antone Roundy <[email-masked]>
Date: Wed, 14 Jul 2004 13:06:31 -0600

On Wednesday, July 14, 2004, at 10:40  AM, Sam Ruby wrote:
> Antone Roundy wrote:
>> -1.  I don't see any reason not to require timezone info in all 
>> dates, as long as -00:00 (unknown) is allowed.
...
> "this timestamp has been canonicalized to UTC".
Ah, got it.  In that case, would the following be appropriate?

a) Timezone's aren't required for any subjective dates ("display") that 
make it into the spec (for compatibility with existing systems).
b) ...but if the DO specify a timezone (assuming we require them to be 
ISO 8601 (is that right?) dates), the timezone must be numeric or Z 
(meaning that things like "PST" aren't allowed).
c) All objective dates (assuming we require a timezone) must 
canonicalize to UTC and specify -00:00 as their timezone.

I would think that if we require canonicalization to UTC, that -00:00 
would be the appropriate way to express it, rather than Z or +00:00, 
which seems (in the presence of the -00:00 option) to imply that UTC is 
the "native" timezone for the entry.  On the other hand, how important 
is this?  I won't cry if we don't require it.

---

From: Dave Pawson <[email-masked]>
Date: Wed, 14 Jul 2004 20:23:12 +0100

On Tue, 2004-07-13 at 21:11, Asbjørn Ulsberg wrote:
> entries. _All_ tools has this action.

And what about people generating atom content?
Cut and paste from ....?

regards DaveP

---

From: Sam Ruby <[email-masked]>
Date: Wed, 14 Jul 2004 15:28:25 -0400

> make it into the spec (for compatibility with existing systems).

We don't have consensus on that, but yes, that is what I would advocate.

> (meaning that things like "PST" aren't allowed).

Time zones in ISO 8601 (and therefore in all profiles of ISO 8601, 
include W3CDTF and RFC 3339) are expressed numerically.  PST is not allowed.

> canonicalize to UTC and specify -00:00 as their timezone.

Some people feel that way.  I don't.  My read of RFC 3339 is that the 
IETF does not, in general, feel that way.  But, yes, if that turns out 
to be the consensus, then specifying -00:00 would be appropriate.

- Sam Ruby

---

From: Danny Ayers <[email-masked]>
Date: Wed, 14 Jul 2004 21:28:36 +0200

+1

Some more justification: *published* is the key word on the web, not 
created. The lazy vendor may fall back on modified == changed 
significantly, but that's not a major problem, the discerning customer 
can work around that.

These dates are primarily for machine-processing (search, sort, display 
order). A date like "issued" as a display date is a different thing - it 
should be part of the content, perhaps as an namespaced extension, or 
alternately:

<atom:entry...>
   <atom:content>
         <xhtml:p>blah blah</xhtml:p>
         <atom:date> 16th July</atom:date>
   </atom:content>
   <atom:issued>2004-07-12...</atom:issued>
   <atom:modified>2004-07-13..<atom:modified>
</atom:entry>

Cheers,
Danny.

-- 

Raw
http://dannyayers.com

---

From: "Roger B." <[email-masked]>
Date: Wed, 14 Jul 2004 14:33:35 -0500

> but I guess some do.

Tim: I keep thinking "import/export", but now that I consider it a bit, it
might be better to save that for an archive:created extension or something.
If you take away atom:created, it should be easier for publishers to intuit
the relation between the remaining date elements and their own app's output.

Here's a list of date-related entry tags from various apps:

Blogger: 
<$BlogItemDateTime$>

MT: 
<$MTEntryDate$>
<$MTEntryModifiedDate$>

WordPress: 
<?php the_date('Y/m/d','before','after',display); ?>

BigBlogTool: 
/.timestamp

ExpressionEngine: 
{entry_date}
{edit_date}

JournURL: 
<weblog:date type="published">
<weblog:date type="updated">
<weblog:date type="created">

Looks to me as if picking the right date for the right element would be
pretty easy for most template systems if "created" is taken off the table.
As long as there is an atom:created in the core, I suspect there will be
people scratching their heads and trying to figure out when to use it and
what goes in it... all for no immediate benefit, at least in terms of pure
syndication.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 21:59:29 +0200

On Wed, 14 Jul 2004 09:21:11 -0700, Tim Bray <[email-masked]> wrote:

> This minor/major thing is an invitation to endless hairsplitting  
> disputes.

Not when people want it, and are exploiting the vague description of both  
Dublin Core and Atom to use 'issued' to signify «major updates» and  
'modified' to signify «minor updates». If this is something people want,  
Atom should define a rigid mechanism for it, instead of leaving all the  
details up to the implementor.

Dublin Core has the semantics regarding this functionality defined in the  
'relation'[1] element. Atom can be more explicit on the semantics and say  
that 'modified' is only to be updated when typografical erratas are made  
to an entry. Effectively rewriting a whole entry is something people would  
be interested in telling about, and this is something I can understand.  
What they then should do is issue a new entry with a new ID and a  
<relation> elements that has an 'is-part-of' attribute that points to the  
old ID.

Minor changes is reflected in atom:modified, while major changes is  
already supported, because the ID of the story (not the original entry  
itself -- it should be left untouched) changes.

> It's a binary decision: is it major enough for the change to be
> reflected in the feed, yes or no.

I agree to this for the current Atom model. 'issued' should not be  
altered, only 'modified'.

> Without a shared definition of what major/minor *means*, this
> will produce zero interoperability.

It is a mighty simple explanation, but some people might have trouble  
comprehending the difference between «small typographical changes» and  
«major rewrites that potentially changes the meaning of the article» -- I  
don't know. There are of course borderline cases between minor and major  
changes, but those seem so rare that I don't think it's worth ponding much  
on.

What's great about this solution is that it's opt-in. If you want «major  
change» functionality, use the <relation> element and issue a new entry.  
If not, use the <modified> element. The support for <relation> is optional  
both on the consumer and producer side, but everyone still gets what they  
want out of the Atom model since it natively supports both.

What would be very problematic is if someone redefined the meaning of  
'issued' to mean 're-issued' or 'last-issued', because then it would be  
impossible to know what to do when facing the 'issued' element.

About the opt-in of <relation>; it does not impose any problems on either  
the producing or consuming side, as explained below:

---------------

We have a scenario of two users writing in their own and reading each  
other's blogs, and a third user just reading the other's blogs. The  
authors are Anne and Peter, while the reading user is Elisabeth.

Anne uses an authoring tool called «Simple Type» that does not support  
<relation>. She uses an aggregator called «Simple Read» that also doesn't  
support <relation>.

Peter uses a combined authoring and aggregation tool called «Complex Type»  
that does support <relation>.

Elisabeth uses «Complex Read» which supports <relation>.

1. Anne publishes an entry onto her blog, called «My cat is five years  
old!». This entry shows up in an Atom feed with the date 'issued' set to  
the (objective) published date of the entry, and the 'modified' date set  
to the same date.

2. Peter fires up «Complex Type» to read Anne's latest writings. The entry  
«My cat is five years old!» shows up, because it has a new atom:id which  
his aggregator has never seen before.

3. Elisabeth fires up «Complex Read» to read Anne's latest writings. The  
entry «My cat is five years old!» shows up, because it has a new atom:id  
which her aggregator has never seen before. Elisabeth closes «Complex  
Read» and turns off the computer because she has to go to the store.

4. Peter presses the [Write about] button in «Complex Type», which opens a  
new edit window with the subject «My cat is five years old!». Peter edits  
this subject so it says «Anne's cat is five years old!». He then writes  
some words about Anne's cat, how it's so smart it can open doors all by  
itself, and so on. During the writing process of this entry, he saves it  
several times.

5. Peter publishes the entry onto his blog. This entry shows up in an Atom  
feed with 'created' set to the first time he pressed [Save], 'modified'  
set to the last time he pressed [Save] and 'issued' set to the time he  
pressed [Publish]. The entry also contains a 'relation' element with the  
attribute 'is-based-on' set to the ID of Anne's entry.

6. Anne fires up «Simple Read» to read Peter's laterst writings. The entry  
«Anne's cat is five years old» shows up  because it has a new atom:id  
which his aggregator has never seen before. The aggregator does not show  
or do anything special with the 'relation' element, because «Simple Type»  
does not support it.

7. Anne realizes when reading Peter's entry that her cat isn't five, but  
four years old. «Oh my god, how embarrasing», she thinks, and rushes to  
edit her entry and correct the error. She opens up «Simple Type», finds  
the entry «My cat is five years old!» and edits the subject to say «My cat  
is four years old!».

8. Anne presses [Save] again, which instantly publishes the changes to the  
web («Simple Type» doesn't have support for drafts). The entry now shows  
up in her Atom feed with the same 'issued' date, but with an altered  
'modified' date, set to the time she pressed [Save].

8. In the meantime, Peter has written some entries about trivial stuff  
like what he has done that day, his excitement of soon having holidays and  
such.

9. While writing, Peter notices that something has happened in Anne's  
weblog. He is so interested in what goes on at her blog, that he's set his  
aggregator to «Show all changes» on her feed. He has set many other feeds  
to «Only show significant changes», because he's not so interested in the  
small changes authors of them do. When Peter opens the «Anne» folder in  
«Complex Type», he sees that «My cat is four years old!» is in bold. He  
notices that the title has changed and that the cat is not five, but four  
years old.

9. Peter immediately switches to the entry view of «Complex Type» and  
selects his «Anne's cat is five years old!» entry. He then presses the  
[Rewrite] (but not [Edit]) button, because he wants to add some major  
parts to his entry about how absent-minded Anne can be, and not only  
change the title. A new window, containing a copy of the old entry, opens.  
He edits the title, appends two paragraphs at the top explaining in a  
humorous way the error Anne has made, and how lost she can be sometimes.

10. Peter publishes the entry onto his blog. It has now 'created' set to  
the first time he pressed [Save] in this entry (which he pressed two times  
this time), 'modified' set to the last time he pressed [Save] and 'issued'  
set to the time he pressed [Publish]. The entry also has two 'relation'  
elements. The first has 'is-based-on' set to the ID of Anne's entry. The  
other has 'is-version-of' set to the ID of the previous entry he wrote  
about Anne's cat.

Moreover, the original entry Peter wrote is altered and a 'relation'  
element is inserted that has an attribute 'has-version' which points to  
the new entry Peter wrote.

11. Peter publishes a couple of more entries to his blog before he throws  
in the towel and goes to bed.

12. Elisabeth is now home from the store, so she turns on her computer and  
opens up «Complex Read» to see if there are any news. Elisabeth, which  
also subscribes to Peter's feed, notices that he has written an entry  
called «Anne's cat is four years old». She has not seen the entry «Anne's  
cat is five years old» on Peter's blog, because that entry is pushed off  
of Peter's feed.

In «Complex Read», Peter's entry shows up just as in Anne's «Simple Read»,  
but it has an additional «related» button that opens up a small dialog  
window showing Anne's corrected entry «My cat is four years old!».  
Elisabeth remembers that Anne wrote that her cat was five years old, so  
she inspects the «related» window further. It also has a reference to  
Peter's entry «Anne's cat is four years old».

13. Elisabeth clicks Peter's related entry and it opens in a new window in  
«Complex Read». She then reads the old entry, and sees that it shows  
«related» which points to the new and updated entry on Peter's blog. As  
she hasn't read the newest entry yet, she clicks the title which brings  
her to it, and she reads it and gets a good laugh about how silly Anne is  
to forget how old her cat is.

---------------

I'm not sure if this scenario explains anything, but I hope it does. It  
should show that the support for <relation> is highly optional, that it's  
a simple and effective construct, and that the core of Atom could support  
it relatively as-is. It also proves that if Atom isn't going to have  
<relation> in its Core, Atom should not try to solve the «minor» and  
«major» change problem in another proprietary way, because this is the  
common mechanism for re-issuance of stories; not randomly modifying an  
'issued' element.

Sorry about the extreme length of the e-mail, and thanks for reading this  
far!

____

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 22:14:51 +0200

> So we have dropped

I hope we haven't dropped anything, yet.

> creation date

Since 'created' is optional, it does not provide the same, no. If  
'created' were required, 'issued' _could_ be seen as the same, but in a  
strict publishing context, they are just as different as 'created' and  
'modified'.

> or objective major modification date isn't it?

Not at all. Not even close.

> #5 subjective creation date, #6 and #7 subjective modification dates - I  
> think that the only subjective date worth keeping is the display date.

+1. And it should not be called 'issued', because issued asserts that it's  
formal which I think outrules any subjective meaning to what the date is.

> #2 except for the last instance -  Keeping archived modification dates  
> around without anyway of obtaining the old copies seems pretty useless.

The problem of «missing entries» or «holes in the entry chain» is a  
something we have to deal with at some time either way, so excluding and  
banning all functionality that _might_ in an extreme case require a  
solution for the problem, is imho very restrictive.

> I imagine any supercedes proposal will come up with something more  
> useful,
> maybe involving <link>

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

> #3 objective minor modification stamp.

I agree.

> I think we only need keep the last modification date though, not the
> whole history.

I agree with this as well, but if an author would like to provide the  
whole history of an entry, he should be able to. PaceIssuedAndRelation is  
an opt-in solution for this.

> This field should be required if the post has been modified in any way.

As should 'created' and 'issued', imho. 'Display' is the only date I think  
should be optional, although many users and tools will provide it anyway.  
It's imho the date least useful in a publishing and syndication process,  
although maybe useful in the display of an aggregator and for the author,  
somehow.

> Some people are suggesting that it is better to have a supercedes  
> mechanism than to qualify changes as minor or major.

I've also suggested using several <issued> elements to indicate that the  
entry has been issued on several occasions. The concrete proposal for this  
is PaceMultipleIssued[1].

  Technically it may be better, but my opinion is that a supercedes  
mechanism
> imposes a more complex workflow on publishers than simply allowing them
> to change existing posts, so I would prefer it if both "major updates"  
> and
> "supercedes" were both allowed so that the publisher can decide what is
> most suitable.

-1. PaceIssuedAndRelation is 100% opt-in for authors, consumers,  
publishers and aggregators, and it would be a huge mistake to have two  
different ways to express not the same, but _amlost_ same thing. If you  
need to choose, it should be between «change support» (only modification  
of 'modified' to indicate changes) or «minor and major change support»  
(modifications of 'modified' indicates minor changes, a new entry with  
<relation> to the old one, indicates a major change).

> If people want supercedes instead, then they just don't use the "Updated"

Again, -1 to that.

____
[1] <url: http://intertwingly.net/wiki/pie/PaceMultipleIssued>

---

From: Sam Ruby <[email-masked]>
Date: Wed, 14 Jul 2004 16:56:02 -0400

> what goes in it... all for no immediate benefit, at least in terms of pure

Roger, you see a pattern that I don't yet see.  I see a list of 
applications, some with one, two, or three different dates.  But the 
idea of doing this bottom up REALLY appeals to me.  So: to aid my 
comprehension, I have made an attempt to collate these dates:

   http://www.intertwingly.net/wiki/pie/BlogToolDateSurvey

I'll readily admit that I took some guesses here... feel free to correct 
me where I went astray.

Once we have the shape of the table correct, lets see if we can get a 
few more rows filled in.  I can investigate the answers for Blosxom and 
perhaps even Radio.  Perhaps others can pitch in.

Then we can try to label the columns.  That surely will be 
controversial.  And take a first pass at which ones belong in the core, 
and which ones are good candicates for extensions.

Once that is done, we can try to provide a prose description for each 
column, and go back and verify how well such a description matches with 
each tool.

Finally, we can settle on the cardinalities (min and max) for each 
column.  And revisit the core/extension decision for each.

And then perhaps we can retire the eight current PACEs which are related 
to dates, and replace them with one around which we have consensus.

- Sam Ruby

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 23:03:20 +0200

On Wed, 14 Jul 2004 10:46:59 -0700, Tim Bray <[email-masked]> wrote:

> LiveJournal and so on.

I would like an 'issued' too, thank you. You can't put anything on the web  
without 'issuing' it, hence all tools in existanse has and performs this  
action, thus should it also be incredibly simple to provide such a date.  
Why I, for one, would need such a date is explained in length at several  
occasions, and is summarized with: It is important to know when a story  
was originally written and/or issued to know be able to set the original  
context of the story before reading.

> The canonical case would be a travel diary, the entry for July 1 may
> have been created on July 3 and modified on July 8, but from the
> user's point of view it's still the entry for July 1.

Then it's 'created' and probably 'issued' July 1st, and 'modified' July  
8th. What the user-provided date is set to is of no interest to any of the  
uses I see that NRK and ePerSpace will ever have with Atom (as an input,  
not output format).

> Frankly I don't see any interesting current or future use for "created"  

I do, I do! :-)

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 23:14:24 +0200

> And what about people generating atom content?

Could you elaborate on «generating atom content»? Do you mean by hand? In  
how many cases do you think that will happen, and nonetheless, don't you  
think people that does this is able to read the specification to find out  
what the different dates are to be used for?

> Cut and paste from ....?

I don't understand this question, sorry.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 23:10:14 +0200

On Wed, 14 Jul 2004 13:58:22 -0400, Sam Ruby <[email-masked]>  
wrote:

> normatively specified in the standard

How can 'issued' be tool-specific? How is it possible to put a resource  
anywhere on the web without performing an action at a time that equals  
'issued'? As far as my brain can stretch, absolutely all tools need to  
'issue' entries onto the web site and into the feed no matter what dates  
they provide, and timestamping this action onto the issued entry would not  
require more than two lines of code in most languages and implementations.

> particularly if the third date ("created") is not present at all in the
> standard.

I could live without a 'created', but we need to have some date that  
indicates when the entry was first made available -- when it is from.

>      aggregator.

Maybe not by an aggregator, but I see its uses in what I and my company  
will do with Atom feeds. 'created' is, however, not as important as  
'issued'. No matter what, both of these dates should be provided by tools  
and should not be subjective. And they should never ever change.

> standardization process, then so be it.

Yes, I could live with that.

---

From: Graham <[email-masked]>
Date: Wed, 14 Jul 2004 20:17:12 -0400

On 14 Jul 2004, at 12:21 pm, Tim Bray wrote:

> a shared definition of what major/minor *means*, this will produce 
> zero interoperability. -Tim

You can sidestep this by saying that publishers *have the option* of 
using <updated> when they have made major changes, and to actually say 
that it is intended to have the effect of bringing the entry back to 
the users attention (how to word that effectively, I have no idea). 
That way, publishing systems that don't make any distinction just don't 
update/use the element, which will simply have the effect of not 
bringing any updates to the end user's attention. Publishers who do use 
the element simply need to ask themselves "Do I wish yo bring these 
changes to the user's attention?". I think it has a good chance of 
working.

(Obviously this is very specific to aggregators)

Graham

---

From: Sam Ruby <[email-masked]>
Date: Wed, 14 Jul 2004 21:45:51 -0400

Graham wrote:

> that it is intended to have the effect of bringing the entry back to the 
> users attention (how to word that effectively, I have no idea). That 
> way, publishing systems that don't make any distinction just don't 
> changes to the user's attention?". I think it has a good chance of working.
> 

+1

- Sam Ruby

---

From: "Roger B." <[email-masked]>
Date: Wed, 14 Jul 2004 22:34:30 -0500

To Sam:
> You

Yikes! If that's what people have been talking about when they discuss
"subjective" or "user-defined" dates, then I have been very, very confused.

When I use those terms, I am referring to an actual date. The user enters
"2004-07-14", "07/14/2004", or "Wed, 14 Jul 2004", and the app parses the
submitted data into a raw date that is tucked away in the database. During
output, the date is transformed into whatever format (822, 8601, etc.) is
required by the user's template. 

So I am most definitely *not* arguing in favor of forcing aggregator authors
to figure out how to sort arbitrary strings masquerading as dates. What I
*am* arguing for are:

(1) The Atom-equivalent of RSS pubDate. Meaning, a date that indicates where
an entry falls within the chronological flow of a blog/feed.

(2) An understanding that (1) may be user-defined (see above), and that the
user may change the value of (1) at whim.

(3) A "this entry was last updated at this time" element, usually referred
to in Atom terms as "modified" and usually machine-defined.

If necessary, I can also provide a distinct "created" date, but outside of
migration between tools, there's not much value in it.

---

From: Tim Bray <[email-masked]>
Date: Wed, 14 Jul 2004 21:01:43 -0700

> to figure out how to sort arbitrary strings masquerading as dates. 

My best take at this time from following these threads, although this 
isn't at the front of our work queue, is that I do not see much chance 
of getting consensus on any dates other than these two, which (if I 
understand correctly) are the same two that Sam and Dare have been 
arguing for. -Tim

---

From: Walter Underwood <[email-masked]>
Date: Wed, 14 Jul 2004 22:30:25 -0700

--On Wednesday, July 14, 2004 5:36 PM +0100 David Powell <[email-masked]> wrote:
>
># 3 objective minor modification stamp.
>
> -1 to dropping this.
>

For search engines, I agree. A search engine will read the feed
and decide whether something should be revisited. The last-modified
date is required for the most up-to-date index.

wunder

---

From: Sam Ruby <[email-masked]>
Date: Thu, 15 Jul 2004 07:49:18 -0400

Roger B. wrote:

> To Sam:
> 
>> You described this date as some fanciful user entered date that
>> could potentially be meaningless. What MovableType and co provide
>> is a way for the user to specify the issued date which is not the
>> same as the user being able to say "43rd day of the 31st month of 
> Yikes! If that's what people have been talking about when they
> discuss "subjective" or "user-defined" dates, then I have been very,
> very confused.

Roger, you weren't confused.

> So I am most definitely *not* arguing in favor of forcing aggregator
> authors to figure out how to sort arbitrary strings masquerading as
> dates. What I *am* arguing for are:
> 
> (1) The Atom-equivalent of RSS pubDate. Meaning, a date that
> indicates where an entry falls within the chronological flow of a
> blog/feed.

The RSS 2.0 definition of pubDate is as follows: "Its value is a date,
indicating when the item was published. If it's a date in the future,
aggregators may choose to not display the item until that date."

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg07000.html

---

From: David Powell <[email-masked]>
Date: Thu, 15 Jul 2004 14:10:52 +0100

> Roger, you weren't confused.

Sam, just to be clear, when you said that the user should be able to enter:
"43rd day of the 31st month of the millionth year" did you literally mean that
the value of the display date field could be that string as free form text?  I
thought that Roger was objecting to that, and I would object to that too.

If people want to associate fanciful future dates with an entry then that is
fine by me, as long as the date is a) machine readable, and b) a valid date:
43-31-1000000 is not a valid date, at least according to RFC 3339.

I would like this date to be machine readable so that it can be formatted
according to the local conventions and capabilities of the reader.

> > user's point of view it's still the entry for July 1.

Yes, I also think that Tim's example is a good use-case.

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Thu, 15 Jul 2004 14:30:17 +0100

Quoting myself: 
> "43rd day of the 31st month of the millionth year" did you...

Sorry Sam, I just attributed the "43rd day..." quote to you when really it was
Dare that said it.

I don't think that either you or Dare was arguing that display dates should be
free form were you?

-- 
Dave

---

From: Sam Ruby <[email-masked]>
Date: Thu, 15 Jul 2004 09:44:24 -0400

David Powell wrote:

> the value of the display date field could be that string as free form text?

Note that I did NOT say that.  It was said TO me.

Roger was not confused.

I would like people to be able to pick whatever date and time meets 
their fancy.  I would furthermore like such dates be accurately recorded 
consistently and correctly according to whatever profile of ISO 8601 
that we settle on.  (Current wording suggests W3CDTF; RFC 3339 is 
actively being discussed; and whether or a time zone indication is 
required on this one particular date remains an open question).

I hope this clears things up.

- Sam Ruby

---

From: Ken MacLeod <[email-masked]>
Date: 15 Jul 2004 09:29:43 -0500

Sam Ruby <[email-masked]> writes:

> The RSS 2.0 definition of pubDate is as follows: "Its value is a
> date, indicating when the item was published. If it's a date in the
> future, aggregators may choose to not display the item until that
> date."
> 
> > The canonical case would be a travel diary, the entry for July 1
> > may have been created on July 3 and modified on July 8, but from
> > the user's point of view it's still the entry for July 1.

I'm not sure if we're to the part about picking labels for these
meanings yet, so I'd just like to note that I think this meaning falls
outside of the meaning of DC 'issued' and Atom should use a different
element localname to encompass this meaning to avoid confusion with
DC.

I am fine with this meaning itself, if that works for us.

  -- Ken

---

From: Dave Pawson <[email-masked]>
Date: Thu, 15 Jul 2004 19:22:56 +0100

On Wed, 2004-07-14 at 22:14, Asbjørn Ulsberg wrote:
> Could you elaborate on «generating atom content»? Do you mean by hand?
Yes. Perhaps in an editor.
>  In  
> how many cases do you think that will happen,
No idea. tens of K's?

>  and nonetheless, don't you  
  My point related to date formats, and being too complex, i.e. to the
second, rather than date+time.

Yes. I'm saying that the 'tools' to generate such a 'full' date may
not be to hand, which makes it harder to produce valid content.
If I look at the computer clock, and can type the date/time, I'll maybe
do it. If its hassle, its unlikely to be done at all.

Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 16 Jul 2004 09:18:38 +0200

> I prefer something that more closely captures Tim's description [1]:

I strongly oppose having just two dates when one of them is unreliable and  
useless (the equivalent of 'Display') and the other is useless for  
syndication and publishing processes in general (the equivalent of  
'Modified' whatever it gets named).

It would be a great loss if Atom Core was not able to deliver an initial  
'created' or even better, 'issued' date in 1.0. It would have enormous  
effect on what Atom could be used for in publishing processes.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 21 Jul 2004 01:21:19 +0200

> do it. If its hassle, its unlikely to be done at all.

That's why users shouldn't do this at all. The tools should provide the  
dates that are useful for other tools. Users MAY provide dates that are  
useful to other users, but I see this as an absolute non-requirement.