Every ENTRY element (in the Atom namespace, obviously) can contain three type of date elements:
CREATED (optional; the same as MODIFIED when left out)
ISSUED
MODIFIED
Some people think Atom has too many date elements and the requirement that at least two of those date elements have to be in the feed is ridiculous compared to RSS, which doesn't require a single date element. Well those people are, to put it simply, wrong. Dates are essential, they are when of weblogging. You could of course mention that your publishing tool doesn't support it; well, you just discovered a bug. Dates are relevant on the web. Make sure you support them before you are outdated. A closer look to the elements:
CREATEDISSUED) in the future, MODIFIED will be the same as CREATED. If publication and creation happens at the same time, all three dates are the same. If the entry is CREATED and the publication is postponed but the publication date is changed after a while, MODIFIED will change accordingly.ISSUEDMODIFIED element value should be reset to "now", since a part of the entry changed. There are some rare occasions were it might make sense to republish an entry since the overall value of the entry has changed thanks to a major revision to incorporate new discovered facts (a year later) or to address the 20 bugs addressed in the comments of the same entry. In that case the ISSUED element value should be changed to reflect the new publish date. MODIFIED should change accordingly.MODIFIEDCREATED and ISSUED to know when it should be changed.For "dynamic" software (generating pages on request) it might make sense to base the URI on the CREATED element. Since that is the only element that shouldn't really change. To be sure and a probably more correct way is to add a separate database field which will be filled when the entry is first published and never changed after.
Slightly related; publishers are encouraged to make a separate field for the entry ID, since it should never change. This way the ID structure can be changed later, but it won't overwrite earlier used IDs, which prevents changing of the elements value.
I hope I didn't miss any important parts giving a inccorect entry, but I can always address those comments with a simple change or clarification.
Coincidentally, I wrote at length this morning about my frustration with feed-level modified. Here, the tools get it wrong every time and a quick look around the Web -- at feeds by Sam Ruby, Mark Pilgrim, et al -- has made it clear that there is absolutely no consensus.
Ultimately, I think feed-level dates should be optional. I agree, however, that entry-level dates are essential.
What's wrong with being outdated? Not everyone cares for seconds, minutes, or any measure of time.
I agree that at least a datestamp is important for any kind of published document. Whether its evident or hidden somewhere in metadata is irrelevant, so long as it's somewhere.
Also, Atom's abundance of elements is remakably thorough. I could never be bothered to keep track of it all by hand (as Moose does), but I can certainly see the benefits for clients, that's for sure. I've certainly received new entries before that weren't actually new entries but just edits, and though it's a slight annoyance, small problems can easily grow into big problems in environments other than yours.
I've often lamented documents that have no date associated with them. I've more than once looked for information and found documents that look like they're from 1997, but there's no easy way of telling, especially since the quality of Web markup can easily be the same today as it was then. Whether that's a actually problem is not is open for debate, I suppose, but I think it is, personally.
When someone wrote something like the mobile phone surely doesn't look promising, it's quite imaginable that it will die a dishonourable death
around fifteen years ago, the one who wrote that would most likely not be stupid at all. However, if the phrasing was just a little bit different (think: although a few mobile phones have been sold, I don't think this technique has much of a future
), then it might as well have been written around 1995. Then, the person would probably be judged as being stupid by the reader.
But of course, to take such a risk is the choice of an individual. If I wouldn't want to attach a date to something I write, I would stick my middle finger up to those who would say I should. I just happen to like attaching dates (automatically) to what I write for myself and that others may benefit from it as well is just a side-effect...
Good argument. Oh wait, your argument is that they are required because dates are important. Hmmm! I guess they are, that's why RSS has date elements too! That doesn't mean they are required. Your argument doesn't follow. It would follow if you had a proof that entries should always have dates. Importance doesn't imply required. Sorry!
Randy, remember to specify a version for RSS. Vanilla RSS 0.91 only supports a channel-level date, not item-level.
Randy, entries should always have dates. A document or article or report on something is possibly worthless if there is no date present. You can create a remarkably well-written essay on the current situation in Iraq, but if you put no date on the essay, it might as well have been written 20 years ago and suddenly the essay is completely worthless.
Dates give value to a topic, because time changes everything, nothing lasts, and value is therefore directly inherited from the date of a publication.
Phil, I didn't specify a version because all flavors of RSS have dates. Whether exclusively at the channel level or both channel and item. A version doesn't make my statement and more or less clear.
Faruk, you said "is possibly worthless", not "is worthless". Sounds like there is room in there for entries w/out dates.
my above comment #8 should read 'make my statement any more or less clear.'
Dates are important. I really don't understand people's problem with dates. Is it too much information to handle? Are the tools they use too inadequate to handle dates? What's the problem? Instead of screeching about «dates should not be mandatory!», couldn't someone give a reason for this?
There are several good reasons to have both CREATED, MODIFIED and PUBLISHEDISSUED. I can understand why people have a problem with providing all of them, always, but I would really like to hear one or maybe even two good reason why no date is to prefer in any circumstance.
Randy,
Common sense dictates that people can often deduct the appropriate date for certain major articles or reports or documents. But that's far from always the case, especially in weblogs it's not that obvious at all. Technologies progress very rapidly in this world, and that increases the importance of dates.
A standard like Atom that requires dates is, in my opinion, a good thing - a good decision by the creators, basically. They ensure that people can't "accidentally forget" (read: are too lazy) to put dates in their feed. This decision creates an awareness of the importance of dates, whereas a feed like RSS doesn't really help to make anything more clear, or anyone more aware for that matter. RSS takes an approach that reminds me a lot of IE's approach to accepting HTML: "You know, you're supposed to do this and this, and you totally messed that up, but hey I don't really care, I'll accept it anyway."
Not really what I see as "a good thing".
I really don't understand people's problem with dates. Is it too much information to handle? Are the tools they use too inadequate to handle dates? What's the problem?
Anne is talking about entry-level dates, for which there is adequate support. But as I pointed out above, there is basically no proper support for feed-level dates. My contention is that inaccurate dates -- those generated by tools that have to resort to including an incorrect feed-level date because the spec requires them to include something -- are more harmful than missing dates.
Faruk, You just told me that dates are important and are therefor required. I think it's clear that importance and required are not synonyms.
Asbjorn, Shall, but this thread is about disproving X, not proving not X.
Sorry, I misunderstood the context. If this discussion is about feed-level dates, I agree. They should all be optional. Entry-level dates, however, should (all) be required.