Fwd: Re: HTML5 comments from 4.3.1

[resent to get it into tracker, this time with tracker id! Aplogies!]
i18n-ISSUE-132: Pubdates on article

Date: Wed, 20 Jul 2011 14:59:04 +0900
From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
To: Phillips, Addison <addison@lab126.com>
CC: public-i18n-core@w3.org <public-i18n-core@w3.org>


On 2011/07/19 15:47, Phillips, Addison wrote:
> Hello Martin,
>
> We recently replaced the time zones note. Your link points to the old (2005) version.

Oh, sorry, not sure why I ended up there, but never mind.

> The new one is:
>
>     http://www.w3.org/TR/2011/NOTE-timezone-20110705/

I have reviewed that recently (unfortunately after it was published),
I'll try to send my comments some day.

>> On 2011/07/19 1:13, Phillips, Addison wrote:
>>
>>> 3. Section 4.4.4. The article element's description contains this note:
>>>
>>> --
>>> Note: The time element's pubdate attribute can be used to provide the
>> publication date for an article element.
>>> --
>>>
>>> This note, while interesting, seems out of place? Also, the example given uses
>> an incremental, as opposed to floating, time value. Pubdates are typically
>> intended as floating:
>>>
>>>     <h1>The Very First Rule of Life</h1>
>>>     <p><time pubdate datetime="2009-10-09T14:28-08:00"></time></p>
>>
>> I can't find the word 'floating', or the expression 'floating time value', in
>> "Working with Time Zones".
>>
>> 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 think what you want to say is that the example doesn't use a time zone offset,
>> but should use one, so that it's clear at exactly which "absolute" point in time
>> the publication was made (and thus it's clear e.g. who was first if two people
>> published the same thing (assuming we can trust the stamps)).
>>
>
> No, the example has a zone offset:
>
>     <p><time pubdate datetime="2009-10-09T14:28-08:00"></time></p>
>
> The problem is that the -08:00 probably wants to be omitted to make it a floating date.

I guess I disagree, see below.

> Your comment is right on in the case where we want to have a timestamp.
> But in my day-to-day experience with publication dates, the opposite istrue just about as often.
> The Sunday New York Times wants to have been published on Sunday,
> regardless of what time zone you are in when reading it.

That's okay when it's just about dates. But in my opinion, it's nonsense
if it's about times.

For one point, the Note mentions examples for Floating Time:

"Some examples of floating time events include a user’s birth date, a
document's publication date, a list of official holidays, or the
expiration date for an offer (if not tied explicitly to a time zone)."

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.

> 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.

Regards,    Martin.

Received on Monday, 25 July 2011 07:19:33 UTC