W3C home > Mailing lists > Public > public-i18n-core@w3.org > July to September 2011

Re: HTML5 comments from 4.3.1

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Wed, 20 Jul 2011 14:59:04 +0900
Message-ID: <4E266EA8.70602@it.aoyama.ac.jp>
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 is true 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 Wednesday, 20 July 2011 06:00:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 July 2011 06:00:24 GMT