Re: HTML Time Zone proposal

On Mon, Feb 9, 2015 at 6:29 PM, Phillips, Addison <addison@lab126.com> wrote:
> Hi Cameron,
>

Hi Addison,

> (this is a personal response; chair hat off)
>
> I don't think that's a good idea.
>

Ok, thanks for your reply. I'm a little surprised by your response as
i read you are an author of ISO 6067. I have a few questions which i'd
appreciate your thoughts on.

> A user's time zone has nothing to do with their language or language preference.

Part of a locale includes a region designation which is a geographic
component, so i would say that it's harder to remove location from
locale and purely define a locale as a language and void of geography.

While the region can not be used to ascertain the time zone for a
localization there are a large number (possibly majority) of cases
where it can. In the absence of any other information i would suggest
that using the locale is the only form of information available to
provide a default time zone.

> Similarly, the time zone a particular page author wants to use is independent of the language/localization of the page.

There are 2 cases to examine for time zones - where the time zone is
fixed with a specific location for its interpretation and where the
time zone should be applied based on the location of the user.

The first case is primarily for any form of event which is tied to a
real world event, for example transport and ticketing.

The second case is primarily when you need to present a event that
occurred which is relatively unrelated to location or when the
perspective of the user is required for interpretation. So here, the
time of email receipts or any kind of personal user application would
make primary use of presentation within the user's time zone location.

So, if we examine the basis for the second case we can see that the
time zone is a component part of the page localization. If there are a
set of events which need to be localized for interpretation by the
user we would need to tailor for their language, cultural and regional
preferences, and for their time zone.

I can see that the first case would suggest independence from
language/localization but isn't this why the -tz designator is a
separate field in the BCP-47 tag - so that it can be configured
independently from the language/region/variant etc?

>In many cases the time zone is likely to be generated from user preferences on-the-fly, which would require parsing and regenerating the language attributes in the page, rather than directly setting or accessing the value.

Given the 2 distinct scenarios which are mutually important i don't
think that predominance can be given to a particular one of them.

If you suggest that the time zone will change depending on the user
then this implies that a tz="" attribute would also need to be changed
per-user.

If we consider the case where we do want to do this then what using
the BCP-47 tags offers is a means to set the time zone either outside
of the document altogether by using the HTTP Content-Language header,
and hence avoiding mutating the page at all, or by setting the pragma
language or <html lang=""> attribute once and have it apply to all
dates/times over the document.

By having a non-externalizable and non-inheritable attribute for time
zone this incurs a greater degree of maintenance and voids external
integration.

> The zone information, when encoded this way, is not scriptable and not amenable to normal HTML/CSS/XML style interaction. Page authors would have a complex time managing the zone. And it would require HTML and CSS to describe specific parsing.

Using an encoding for time zone does incur some additional parsing,
however the information is still scriptable and targetable. APIs are
usually provided to ease the use of specific encodings and document
algorithms.

> I'm aware of CLDR's zone identifiers. I oppose the use of their -tz subtags for open interchange of zone information and I'm mystified about what the CLDR folks are thinking these subtags are useful for in a language tag. I suspect this is so specific implementers can pass a single "bag of international preferences" to a formatter to get a fully formatted result. And I think that's fine for things like number formats or collation options that *are* language/locale related. But time zones are purely orthogonal and shouldn't participate in this.

I think the benefit of including the -tz subtag is so that the
encoding can represent date/time formats. Otherwise there must be 2
sets of information to present a date/time. This seems messy to me and
complicates interchange across protocols and data storage.

> We discussed in earlier iterations of this wiki page allowing both zone identifiers and offsets in date or time values, but this would break existing implementations that do not expect the zone identifier. I'm open to different solutions, but I tend to think that extending unrelated attributes is not the answer.

I'm not too bothered about having zone identifiers or offsets in the
date/time encoding - UTC is generally preferred for communication and
data representation anyway. The only value i would see in having time
zone added to the encoding would be to provide a method for specifying
the default time zone for a date/time where one would otherwise be
unavailable.

I'm not sure weight should be given to existing implementations to be
concerned with regarding zone identifiers or offsets in date/time
values - the date/time encoding is new to HTML5 and any existing
implementations are experimental. The importance of time zone for the
interpretation of date/time instances also highlights that any
existing implementations will be broken and will have inconsistency
across any existing implementations. As such it is not hard to see a
lack of adoption and i believe that greater importance should be given
to getting the specification correct over attempting to cater for a
particular interpretation of what an author might have been implying
through the inclusion of a date/time value on a page.

Thanks,
Cameron

>
> Addison
>
>> -----Original Message-----
>> From: Cameron Jones [mailto:cmhjones@gmail.com]
>> Sent: Monday, February 09, 2015 6:30 AM
>> To: www-international@w3.org
>> Subject: Re: HTML Time Zone proposal
>>
>> On Thursday, August 14, 2014 19:47 +0000 "Phillips,
>> Addison"<addison@lab126.com> wrote:
>>
>> > All,
>> >
>> > Thanks to everyone who responded to the call for comments. I have
>> > updated the document located here:
>> >
>> >    https://www.w3.org/International/wiki/HTML5TimeZone
>> >
>> > I hope that I have addressed everyone's comments fully.
>> > Feedback is still welcome.
>>
>> Could the time zone be defined through the HTML BCP-47 lang=""
>> attribute using the Unicode -tz extensions instead of introducing a new
>> attribute?
>>
>> This would allow a time zone to be set according to the HTML language
>> resolution algorithm which would allow a time zone to be applicable across
>> the entire document, on specific elements, or even with fallback to HTTP
>> headers.
>>
>> It also allows for the flexibility of using time zone identifiers instead of fixed
>> offsets.
>>
>> Thanks,
>> Cameron Jones
>

Received on Tuesday, 10 February 2015 14:17:57 UTC