It’s just data

Subjective and objective dates

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.

If I make a post at 2:30 in the morning, the fact that it was 2:30 in the morning is relevant.  If I go back and correct a misspelling eight hours later, that fact too is relevant - to a different audience or set of tools.

Look at the Update Journal web page.  The local time is pre filled in.  The time zone is not captured.  You are free to edit this field.  In Blogger Pro you can even do this after the fact.  It is worth noting that this time is subjective.  Effectively, it is part of the content.  The ability to specify the time zone, or to leave the time zone off, is of paramount importance for this usage.  Being able to sort this is of secondary importance.

Being able to detect that an existing post has changed, and when, is a vital and important use case too.  The closer this date can come to reflecting when the actual content changed (as opposed to reflecting when, say, a template changed), the greater the value that exists in this information.  This time is objective.  Being able to collate these dates is of paramount importance for this usage.  The time zone is not relevant.

Two different, but related needs.  In most cases, the subjective and objective dates will reflect the same underlying point in time.  But we need both points of view.

The above describes the ideal.  Now lets deal with the practical.  If a last modified date reflects when templates were updated, then some value is lost, but I'd still rather have this information than not have it.  If the dates reflect a time zone when they shouldn't, or don't reflect a time zone at all when they should, then some value is lost, but much value still remains.  In particular, a simple sort method may not be as accurate, but it will still mostly work.

In short, modified should be UTC and issued should reflect the local time zone.  Both should be required.


Is there any problem with only including the modified date if an entry has been modified since it was issued? I very rarely edit my posts so modified would basically be redundant data in my feed most of the time.

On an unrelated note, your add comment form could really benefit from some label elements :)

Posted by Simon Willison at

This is an interesting thought. At first I dismissed it because I've made it a personal rule to manipulate dates in UTC to avoid time zone issues. On second thoughts, the different audiences for the dates makes some sense.

However, a potential problem may come from defining what local time zone means and how the date is stored and processed.

I currently make blog entries in the UK, so for half the year GMT/UTC is my local time. However, we currently have daylight savings time so it's off by an hour. My web server, on the other hand, is (well, I'm not entirely sure exactly where, but it is) 7 or 8 time zones away. If I don't stick to UTC, sometimes I get myself in a mess and various different systems (including me) get confused about which bit is local to where.

Posted by Adrian Bateman at

All times should be universal. Additional information could be added via location information. Consider:
Location could use 1) label ( "House in San Francisco" 2) timezone adjustment 3) Coordinates, etc.
Consider looking at the .NET MyServices Spec -although shelved they did spend some time on it.
General design considerations should be "Look forward, not legacy", "Do nothing unnatural".
Legacy posts should be the exception, and tools can be created and used to bring them to spec.

Posted by theCoach at

Sam,
I believe that we should choose one standard way of expressing all dates. I'm a big fan of expressing everything in GMT/UTC. If the user wants to display the local time, his/her tools should support that conversion based on the user's specifed time zone. This has the benefit of making diff calculations extrememly easy and of making the format simple to understand. There is no need to worry about different dates being expressed in different ways. We can even add the relevant time zone information to the geoLocation portion of the format for consumers of the feed that wish to make use of that information. Your thoughts?

Posted by Christian Romney at

Let me add to my last comment. Both required: +1. Both objective UTC (GMT) dates +1.

Posted by Christian Romney at

Simon - much like I said with permalink and id, "In fact, they will often be the same.  But let's not introduce complex precedence rules or require the recipient to guess for the sake of saving a few bytes of bandwidth in the cases when they are.".  And if you care to make a specific suggestion as to how I can use label, I will likely adopt it.

Adrian - at the moment, subjectively it is 2003-07-01T09:35:00 or 2003-07-01T09:35:00-0400 here.  Objectively it is 2003-07-01T13:35:00Z.  Both are easy to store and represent.

Coach, Christian - please take a moment to ponder how LiveJournal users perceive dates and times.

Posted by Sam Ruby at

In case people are unfamiliar and don't care to research, I'll summarize how LJ users (and LJ itself) deals with times.

There are three times stored for each entry:
Firstly, there is logtime, which is the time the entry was posted as far as the server is concerned. The user cannot change this and it will never be changed by the system after posting. Since the system sets this, the timezone is (theoretically) known.

Secondly, we have entrytime, which is the time given by the user. This is completely arbitrary and the user can set whatever time they like. You can think of this as "display time" as it is only used for display purposes. Due to a historic oversight, no timezone information is stored for entrytime, and since it is arbitrary no guesses can be made based on the difference between logtime and entrytime as the user may have deliberately set the time in the past or future for whatever reason.

Finally, we have the revision time. This is the last time the entry was edited, again set by the server and thus the timezone is (theoretically) known.

The reason for my use of 'theoretically' twice above is that in the past (and I think maybe currently too) the server sets values in local time rather than a specific timezone. This means that LiveJournal.com has some values stored in PDT and others in PST due to daylight savings changes. Obviously this is another oversight from the early days.

Ignoring the minor problem with PDT vs PST (which hopefully will be fixed or has been fixed -- I've not checked), LiveJournal can only reliably give the timezone for time posted and time modified.

Posted by Martin Atkins at

Martin, thanks!  FYI: except for a one hour period ("fall back"), if you know that a time is either PDT or PST, you can reverse engineer which one it was by looking at the time itself.

Posted by Sam Ruby at

Quoting from the original post: "If I make a post at 2:30 in the morning, the fact that it was 2:30 in the morning is relevant. ... Being able to detect that an existing post has changed, and when, is a vital and important use case too."

+1 on both being required

Keeping track of both of these things at once is something I would like to be able to do, but can not do with RSS 2.0 as-is.  There is only 1 pubDate per item; I can use it as a creation date, or as a modification date, but not both.

Posted by Mark at

+1 on both TimeModified and TimeIssued being required.  I don't have a final opinion on the semantics of TimeIssued yet because of a few questions. 

If TimeModified is a required value then what will it contain when an item is first created?  It seems to me that it would contain a value that behaves exactly like the creation time of the item.  If this is true, then it seems that we have three potential data elements here:  TimeModified (always objective UTC), ObjectiveTimeIssued (aka the very first TimeModified value which is also objective UTC) and SubjectiveTimeIssued (subjective time as per the LiveJournal usage scenario). 

Perhaps I'm missing something but if TimeModified is required then ObjectiveTimeIssued is always implicitly available.  Why wouldn't we keep this value around?  It seems like it would be a shame to have objective versions of both times only to throw one away.

Posted by Joe Madia at

Joe, I think Sam's take was that just the objective TimeModified value is required. On creation it would reflect the objective creation time. TimeIssued is the subjective value and because it's subjective it's never really useful in relation to TimeModified. So I'm not sure, but I'm not reading it as an objective TimeIssued is always implicitly available.

+1 for both required, ISO 8601.

Posted by Grant Carpenter at

Addendum: Just TimeModifed value is required == objective TimeModified required plus subjective TimeIssued required.

Posted by Grant Carpenter at

I'm not so sure about the one in UTC on in TZ thing, both times should be fully qualified, the actual TZ used shouldn't be of significance, as long as the resulting time stamp with TZ correction is correct. If the actual TZ is important, then if you post from PDT, but your server is in EDT, which TZ gets used ?

just to clarify, assuming xsd:dateTime,the following would be valid
2003-07-01T18:00:00Z
2003-07-01T11:00:00-07:00
2003-07-01T14:00:00-04:00

but this (which has an asusmed local tz would not)
2003-07-01T14:00:00

Posted by Simon Fell at

Just to clarify, for "issued", I can use either:
2003-07-01T09:35:00-0400 or
2003-07-01T09:35:00 or
2003-07-01T13:35:00Z ?

For "modified", I could only use:
2003-07-01T09:35:00-0400 or
2003-07-01T13:35:00Z ?

Posted by Joe at

Heheh, sorry about that, looks like Simon and I were posting comments at the same time...

Posted by Joe at

Grant: my recommendation is indeed that both are required, trading a small bit of bandwidth for a bit of clarity.

Simon: unless I am missing something, all the above times formats you quote would conform to xsd:dateTime.

Simon/Joe: my take is that the version with a 'Z' would be preferred for modified.  Any of the versions without the 'Z' would be preferred for issued... which of these you would chose would depend on what time zone you felt you were in... as I said, this being a subjective thing.  The validator would issue warnings (not errors) for such things.

Hmmm.... perhaps I should add a little ECMAScript to my comment form to capture the local time from the perspective of the user making the comment.

Posted by Sam Ruby at

I think requiring both is fine.  I usually do dates as all-utc but see the case for keeping the timezone information (but would recommend expressing it as a UTC offset).

Posted by Chris Wilper at

Christian Romney

Sam,
I've looked at the site and see that time zone information is left out. Each user's post seems to be labeled in their own time zone (which has the benefit of being relevant to that user). Outside of that, I'm not really following what you're getting at. Perhaps you could elaborate a bit more? I have the distinct feeling that I'm missing something. I keep thinking the UI could allow the user to select which timezone (if any) they want to see all dates on a page in, to have everything expressed from a common point of reference. In other words, all the math is abstracted away from the user while still giving him or her the ability to view the information in the most natural way. The blogger example you cited is interesting in that it allows you to post to the future or the past. This is cool, but, again, is a tool-based piece of functionality in which irrelevant TZ info is irrelevant. TIA

Message from Christian Romney at

Christian Romney

What I don't see a need for is to store both subjective and objective time. Actually, TZ is a location dependent thing, which can change very rapidly if you are on a flight. The subjective can always be calculated from objective. Storing everything the same way eliminates ambiguity and establishes a frame of reference.

Message from Christian Romney at

Sam,
  Thanks for the clarifications. That looks great, particulary about the validator issuing only warnings and not errors.

+1

Oh, and +1 for the JavaScript thingy noting when people started to post a comment. For those of use that type slowly :)

Posted by Joe at

it seems to me that you're trying to hide a bit of data (timezone that a particular time was specified in) within the format of that bit of data (a generated or user-specified timestamp).

this seems unnecessarily fragile to me. someone trying to learn the format by example may miss such a subtlety entirely. so might someone reading even a clearly-written specification.

or it may be best just to not distinguish between these different timestamps with regard to how they specify a timezone -- an aggregator will always be free to either display that time in the timezone it was specified in, or convert it to a local one. (personally, an aggregator i would write would likely always display timestamps in my local timezone, but perhaps make the time as specified available in something like a tooltip.)

(but a huge +1 on the timestamps requiring an explicit timezone, even if it is UTC. it is one of the unfortunate quirks of XML-RPC that it doesn't require that.)

Posted by jim winstead at

The way I see it:

Last-modified and Created are both useful timestamps from a presentation/aggregation point of view.

UTC is the most convenient way of expressing a time so that it's useful to people, from this same point of view.  If I'm aggregating multiple feeds, I don't want to have to convert each timestamp to a common timezone just to get them into order.

The timezone of the person posting it is also relevant to many people, and can vary for people who travel a lot, or in the case of multiple authors per feed.

So, from my perspective, it would be beneficial to have:

Creation in UTC, per entry
Last modified in UTC, per entry
The timezone of the author, per entry

If people want more finely-grained control over updates than that, then they can offer their content in XHTML and make use of the relevant elements (<ins> and <del>, both of which allow you to specify a timestamp).

I don't see what's important about a creation at 2am local time that is not important about a modification at 2am local time.  Modifications can also be important.

For instance, what about if I post in response to somebody saying something stupid, with a reasoned "I think they are incorrect because...", and then, after a long day at work, recieving an email from them, and updating it with "Actually, I take that back, he is an idiot".  The local time this was posted would be significant, to me at least.  (fictional situation btw). read

  * Small Values of Cool
  Updated Tue 14:51
  * The FuzzyBlog!
  Updated Tue 14:49
  * Disobey Nonsense Network
  Updated Tue 13:39
  * Sam Ruby
  Updated Tue 13:05
  * Scripting News

Posted by Jim at

Christian, capturing the time zone is a nice to have for subjective dates.  I agree with Chris, when the information is available, add the time zone information as a UTC offset.  As you said, knowing the time zone has the benefit of being relevant to that user.

A number of people have consistently argued that it would be better if all modified dates were expressed in UTC.  I've always thought that was less user friendly until I came across the way that LJ handles dates.  That's what gave me the insight that different dates may have different needs.

Then I played with the syntax.  Placing the issued and modified side by side, one with the time zone and one in UTC seemed to provide more information, even when (and arguably, especially when) they were meant to identify the same point in time.

Posted by Sam Ruby at

Sam,

I strongly support having both dates, ideally both dates being required, but I can live with ModifiedDate being optional if no modification has occurred. 

I strongly support making both dates (all dates, really) OBJECTIVE.  Ths makes cross-blog threading and comparisons much much easier - then everything is unambiguous, and all you have to worry about is clock skew between machines :-)

Posted by David Sifry at

Sam, I think I see what you are saying now. Basically, capturing the TZ of the creator so the reader [even if (s)he is viewing the dates and times subjectively] can still see the time zone information of the original poster. Like this:

"Blog Entry Title"
...content...
  Local time: 3:00 PM PDT (posted by Sam Ruby at 6:00 PM EDT)

Is this what you mean? If it is I could see how that is useful. I know the exact time of the post as well as the relative distance between your time zone and mine. Local time is displayed if my time zone is known, otherwise I could default to UTC. Your subjective time is known based on your TZ info which I think should be part of the post, but I would prefer it in geoLocation (along with Lat+Long although that's a different topic entirely). This brings up an interesting thought -- perhaps a geoLocation should be added to each entry. It would be cool to see a traveler's blog and view your entries on a map like the old Indiana Jones movies used to start... :) In any case, thanks for the expanded clarification.

Posted by Christian Romney at

I use MT for as the CMS for a site LibraryLines that simply serves as an archive for a newspaper column. All the dates shown are the date of publication of the column. The time at which the column was actually entered (either sometime the week before or several years after) is completely irrelevant.

Posted by Michael Pate at

I'm strongly against 2003-07-01T10:00:00 being allowed, as its defined as being in the users timezone, which isn't a very well defined concept, who is the user ? which exact timezone is it ?, how to i tell my software reading this data the timezone ?.

Posted by Simon Fell at

Sam: This is still nagging at my brain...  if the "modified" value is required to be present and it is also required to be UTC then it would appear that its very first value would be a perfectly objective "issued" value for each item. 

It feels to me like we're throwing away some extremely valuable data here.  Why not save a copy of the initial "modified" value (call it "created") and keep it around along with "modified" and "issued"?

Posted by Joe Madia at

Simon, I have talked to Noah Mendelsohn, one of the authors of xml schema.  The reason why this is in the spec is very simple: there are people who want to record dates and times for which they have no time zones.

LiveJournal is a real tool with exactly this situation.

So, my take: such dates are valid according to xml schema.  The requirement is validated by a real tool that people actively use today.  So, I believe that this has to be allowed.

This being said, in my feeds I will likely provide the time zone offset when it is available.

Posted by Sam Ruby at

I'm +1 on Sam proposal, specially about the subjective date. My use case is I'm offline, and I store something in my PDA which has a strong temporal Bias, such as "At three in the morning, the buses are crowded a Saturday in Madrid", with a digital photo.

I keep drinking ;-), and go home at 5am. When I go to publish, I still want the post to be dated 3am, not 1pm next day. But the timestamp will be the "right" time.

It is part of the content, as Sam says. Not really a technical issue. It is the "when" in the "what, who, how, when, where and why" classic journalism questions.

Posted by Santiago Gala at

Sam,
Why would it be a bad idea to store the timezone in a geoLocation element as such?:
<entry>
... content removed for clarity ...
<issued-date>2003-07-01T13:35:00Z </issued-date>
<geo-location>
  <latitude>26.00278</latitude> <!-- optional -->
  <longitude>-80.22417</longitude> <!-- optional -->
  <timezone>
  <gmt-offset>-5</gmt-offset>
  <name>Eastern Standard Time</name>
  <abbreviation>EST</abbreviation>
  </timezone>
  <country>US</country>
</geo-location>
</entry>

Posted by Christian Romney at

I agree with Simon about the lack of time zone causing problems. RFC3339 provides a profile of ISO 8601 for Internet protocols.

Specifically, it says (4.4):

"A number of devices currently connected to the Internet run their internal clocks in local time and are unaware of UTC.  While the Internet does have a tradition of accepting reality when creating specifications, this should not be done at the expense of interoperability.  Since interpretation of an unqualified local time zone will fail in approximately 23/24 of the globe, the interoperability problems of unqualified local time are deemed unacceptable for the Internet."

Also:

"The offset between local time and UTC is often useful information. For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local offset provides a useful heuristic to determine the probability of a prompt response."

The local time is useful, but I think it should be quantified as an offset from UTC.

Posted by Adrian Bateman at

I think ideally ModifiedTime would be optional but recommended.  There are going to be times when ModifiedTime is nonsensical, or when you feel that publishing it is a privacy leak.  I do however understand the desire to not have optional elements in the core.

I feel very strongly that dates without timezones are a bad idea.  I've done a fair amount of code working with dates, and supporting a concept of "local" time, or what the iCalendar spec calls "floating" time is very very very complex to do well.

Also W3CDTF, the Dublin Core preferred datetime format does not allow dates with time components to be expressed in local or floating time.

I understand that some tools won't be able to emit properly formatted datetimes immediately, but with some encouragement and evangelism I'm sure they'll be fixed.  In the meantime I think any datetime without a timezone component should be assumed to be in UTC.  Anything else is a serious headache.

Posted by kellan at

Data point: JournURL's date handling is very similar to LiveJournal's... creation, published, dateLastModified, with only the published date being user-controlled. And all dates are assumed to be in the server's time zone.

Posted by Roger Benningfield at

On the subjective date, I agree with Santiago and Sam - it's definitely part of the content.  I also agree that the timezone should NOT be included.

Take a paper journal.  When I use one, I'll write over midnight, and may write in it on a trip in a different timezone.  The date is as much a label about my perception of when the entry is meant for as the title is an expression of the entry.

Also, if the timezone information is included, I can't control a tool from displaying that time from my blog in the user's local time.  So perhaps a dialog begins, and the user talks about a post on the 25th, that to me is marked as the 24th.  While such miscommunication could easily be resolved, it becomes an issue of controlling my content so that it's presented the way I want it to be. 

Though I may not care if it's formatted as 10/24/2003 or 24/10/2003 or any other way, the subjective date is definitely content I want control over.

Posted by Tim Shadel at

I think Christian's hit the nail on the head earlier about timezone - the UTC time refers to the moment, the timezone is really about geography.

For 99+% of the time its value will remain the same for a given feed, why bother wasting bandwidth? I'd suggest it goes in with an (optional) extension like GeoURL. The local time can be calculated by any agent that considers it significant.

re. format : the W3CDTF of ISO 8601 has a lot going for it - i18n, standardization, ease of reading/writing, and it sorts well.

Posted by Danny at

I must respectfully disagree with Sam. Both times should be UTC. It is the way they are formatted for presentation that will change depending on their use. Despite what Sam may believe time itself is not subjective it is, by definition, objective. However the way we express time is subjective, it changes depending on our location. So if I am in San Francisco the correct time is calculated by taking UTC and subtracting 8 hours, and, if  daylight saving is in effect, adding 1 hour back. The point is local San Francisco time is relative to UTC. The fact that I set my clock to local San Francisco time is parochialism.  I wrote a longer piece on this subject on my site. Hope this helps.

Posted by John R. Harris at

John,

While I agree with most of your assertions about time and timezones, I don't see how it follows that the times in Echo must be in UTC.

Persumably datetimes in Echo should be in UTC, or provide a method for deriving UTC.  e.g. a numeric offset from UTC of the form +5:30.

Posted by kellan at

Kellan

I agree with much of your previous post, especially the part about how complex this can get. I don’t think there is an easy solution to this, but as long as you stick close to the likely intentions of users you should be ok. I understand why you may want to make UTC optional but I would make several comments.

A datetime without a UTC offset indicator is pretty meaningless. To be precise it defines a 24 hour period. Most users would not understand this and would claim this was an obvious error.  I like your suggestion of making datetimes with no UTC offset default to UTC-0

You say “Presumably datetimes in Echo should be in UTC, or provide a method for deriving UTC” I agree but the method must be unambiguous and handle daylight saving times. I have suggested what I think is the best method in the link I provided in my previous post.

Using an acronym for the name of the local civil time does not guarantee uniqueness. There is no international body governing the namespace for local civil time zones. So CST may mean Central Standard Time in the US or it may means the same thing in Australia or Cuba Summer Time and China Time (UTC-06, UTC+0930, UTC+08, UTC-04 respectively). EST suffers from the same kind of problem.

So you should use the offset from UTC. But combining the offset from UTC and daylight saving is confusing.  It leads to the situation where the same city has two different offsets from UTC at different times of year. So San Francisco is either in UTC-8 or UTC-7. This is nonsense since UTC-8 and UTC-7 are the names of geographical areas and San Francisco does not move! San Francisco is and will remain in UTC-8  but during summer time a further correction is applied (+1 hour). 

So I believe the most rational way to store and transport datetimes is in three parts; date:time, UTC-offset and the daylight saving offset.  For example 2003-07-01:16:00 UTC-8  +1  Which is 9 am in San Francisco.  This format solves three distinct problems
1) any user can compare the UTC time with other UTC time. 2) Any user can reconstruct the authors subjective time and 3) Any user can convert the time into their own local time if they want to.

Posted by John R. Harris at

Slight revision to my previous comment - following W3CDTF would in effect make UTC the primary value, with timezone offset being optional :

"A standard referencing this profile should permit one or both of these ways of handling time zone offsets."

http://www.w3.org/TR/NOTE-datetime

Posted by Danny at

Here's my take on things: if you want to have a subjective timestamp for a post, an objective timestamp for its first publication, and (always or when needed) another objective timestamp for times when a post is modified, fine by me.

However, these discussions regarding how subjective timestamps shouldn't have time zones and how geographic information and/or explicit time zone / daylight savings time information should be used to normalize timestamps are, to be frank, ridiculous examples of corner cases gone wild.

Having worked on (and as a user of) a number of systems which had to simultaneously process and present date and time information from and for numerous time zones and different regional rules as to whether or not daylight savings time even takes place (and if so when) I can tell you the following:

- there is no such thing as a timestamp without a relevant time zone (I am really surprised that an earlier comment would make that claim)
- there is nothing that would bar a subjective timestamp from being recorded in terms of UTC
- no real argument can be made against representing all timestamps in UTC, as the consistency, clarity, and coding simplicity provided by doing so are immense, all while leaving display options completely open.
- if, in the absense of explicit information regarding author time zone and daylight savings rules, an author particularly wants to present date and time information in terms of their local time they should realize that this is a corner case, one largely an issue of content, not one of post-related metadata, metadata which should be tailored for optimal a) processing by aggregation and syndication systems and b) display formatting as per end user preferences.

As a side note: One cannot reliably reverse engineer base time zone and/or daylight savings time status from a timestamp, whether provided with UTC offset or geographical location, without requiring either a local database of information regarding regional time zones and daylight savings time rules or the explicit provision of such information along with the timestamp(s).

Given all of the above, I would HIGHLY recommend the following:

- whether you want to record one, two, three, or fifty-seven timestamps for a post, do so using W3C XML Schema datetime format, normalized to Zulu time.
- allow aggregation software users to display provided timestamps formatted locally or universally and in a style of their choosing
- if an author wants to provide timestamps which are always formatted as per the author's local time, either place it in the content or convince someone to develop an extension module to deliver explicit time zone and daylight savings time rule, name, and schedule information alongside post content (no, providing geographic information won't do the trick without requiring a large aggregation-side database of regional rules) and then convince aggregation software developers to support said extension module, noting that the extension module approach to the third point, while interesting, only supports an uncommon corner case while requiring a good deal of effort on the part of aggregation software authors

Let's try to avoid muddying the waters regarding what's best for the vast majority of cases.

Repeat after me: UTC is my friend. :)

Posted by Jeremy Gray at

Jeremy, the subjective issued date could as well be a string, with examples like "early morning", or "Sep 2003", or "after too much blog reading", though this last is stretching it too far.

I have been seriously considering proposing this possibility, to avoid the kind of discussions we are having, as the "issued" field is not really a timestamp. But I'm not sure if it is even worse.

WRT the other two dates, I agree with you.

What does people think?

Posted by Santiago Gala at

I agree 99% with Jeremy.
However, outside of feeding a list of flight times or some other heavy-lifting-required application of dates times, I see no reason why one would need to have a huge database of tz rules and names. If a content publisher wants to provide the local timezone, the burden of correctness is on that individual. It certainly doesn't lie with the consumer who may only want to display the tz the writer was in as a note to the entry. To that end, I see nothing at all wrong with something linke this being optional.
<timezone>
  <name xml:lang="en-us">Eastern Standard Time</name>
  <abbr xml:lang="en-us">EST</abbr>
  <utc-offset>-5</utc-offset>
</timezone>
If this is for an extension module, so be it. +1 all dates should be UTC.

Posted by Christian Romney at

Santiago - I would argue that 'issued' is not a subjective timestamp at all, and that if any timestamp were to be subjective it might be 'created' (as per the Wiki), but even that would be stretching it. More subjective timestamps like the ones you suggested really don't belong in the set of timestamps upon which software systems are going to be relying.

Christian - Yeah, the main point I was trying to make there is that in order to reverse engineer back from a timestamp to some form of author-local time information one would need either a database or a block of time zone information the likes of which you posted as an example. The need to reverse engineer it in the first place came from a corner case example in one of the earlier comments where the poster stated a desire to post author-local (or even more subjective) timestamps without appropriate time zone information, so it wasn't something that I was encouraging or would encourage in the first place. :)

In any case I still believe that timestamps provided should be in W3C XML Schema datetime format and normalized to UTC in order to bring clarity and consistency, with the latter requirement (UTC only) there if only to make sure that authors (or preferably the authors of the software authors use) have a greater awareness of the issue and don't by mistake slip in a local time without time zone information.

Posted by Jeremy Gray at

Upon re-reading my previous comment, regarding "'created' (as per the Wiki)", by that I meant that if any timestamp were potentially open to more subjective assignment it would be the 'created' construct, and that by 'created' I mean the creation date construct mentioned in the Wiki. I did not mean to indicate that the Wiki defines 'created' as subjective. :D

Posted by Jeremy Gray at

+1 on everything Jeremy Gray just said (UTC for everything).

Posted by Jim Dabell at

Add your comment