Fwd: RE: HTML5 comments from 4.3.1

[resent to get it into tracker]
i18n-ISSUE-132: Pubdates on article

Date: Tue, 19 Jul 2011 23:55:26 -0700
From: Phillips, Addison <addison@lab126.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
CC: public-i18n-core@w3.org <public-i18n-core@w3.org>

> >> 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 Monday, 25 July 2011 07:22:26 UTC