RE: HTML5 comments from 4.3.1

> >> I don't know why you call the time the example is using "incremental".
> >> According to
> >> http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e163,

> >> incremental time is counted in seconds (or whatever) from a
> >> (system-dependent) epoch, and therefore (as far as I understand) not
> >> interchangeable between systems.
> >
> > That's right. It's technically a field-base zone-dependent time (which, as it
> turns out, usually eventually takes the form of an incremental time --- as a
> JavaScript 'Date' object).
> 
> I suggest that if we have our own document with our own terminology, we
> better use it (or change the document).

I *am* using our terminology :-). I admit that this particular term is less clearly defined in the new Note (in part because field-based and zone-dependent are defined separately in the new note).

> 
> If you look carefully, it's all about dates, NOT datetimes. It's perfectly fine if the
> New York Times puts a Sunday date on their Sunday edition, and I would agree
> that such a date wouldn't need a timezone offset.

Yes. Generally speaking, there are floating *dates* and floating *times* but usually a datetime is a timestamp.

> 
> > Providing the offset allows you to compute local time at either the
> > point of publication  or to convert it to your own local time.
> > But if you're not careful,  you'll get point of publication time
> > coerced
>  > into your own local time (and the date changes).
> 
> Well, yes, because it indeed may already be Monday here in Japan even if it's
> still Sunday in New York. For any kind of service that e.g. lists news by novelty,
> not taking the time zone into account would be detrimental. News from Hawai'i
> would be listed at the top even if it were close to a day old, whereas news from
> New Zealand would always be ignored. I don't think we want that.
> 
So the question here is one of the use case being employed. The particular HTML5 comment I suggested might not be reasonable because it's entirely possible that one wants a timestamp (this is what you're describing). If you're putting articles in order by timestamp, then you have one case.

If, by contrast, one is talking about publication metadata, then one might to speak precisely about the publication date (not datetime) and not have which day it is depend on what time zone you're observing it from. This can also work for time values in highly selected cases, and rarely on fully qualified date time values.

The problem I encounter frequently is that the "pubdate" starts out with something like "new Date()" or "gmtime()"---an incremental timestamp---and the hours, minutes, and seconds are an accident (often derived from the zone offset).

The real key is that the content author needs to make a conscious decision about what a given time value is doing and going to be used for so that such issues are avoided.

Addison

Received on Wednesday, 20 July 2011 06:55:54 UTC