RE: HTML Time Zone proposal

John Cowan noted:
> 
> > I agree with your statement. As noted in my earlier comment, I think
> > the alternative (throw out the offsets if tz is present) would have
> > too much potential to break things and lead to unanticipated results.
> 
> This seems to me to undermine the original use case.  The whole point of
> specifying "5:00 PM on 2020-04-01, New York time" is that we do not know
> what UTC instant corresponds to that time, but we may be required for legal or
> customary reasons (consider appointments in the future) to specify just that.  If
> the tz attribute cannot be used to specify the meaning of a timestamp, it is
> useless for that purpose.
> 

I see what you're saying: I think that shows there are three potential problems to be solved here.

Problem 1) Page authors wish to use a real time zone instead of an (incomplete) offset value when sending or receive time values. This is what the alternative at the bottom of the proposal would solve, but at the cost of breaking existing HTML parsers.

Problem 2) Page authors wish to control the display of a date or time value to use something other than the user agent's local time. This is what this proposal does solve.

Problem 3) The user wishes to communicate a time value to the server (as in a form field) including the time zone information necessary for complete processing at the server ("cancel this order at 5 PM New York time"). This proposal doesn't solve this except indirectly (by allowing a time zone such as "America/New_York" to be the one that controls the user agent's display of a time picker control and interpreting the user's response when serializing the results for the server).

[Note that problem 3 suggests the need for input[type=timezone])

Careful implementers will avoid using a local time offset and always use UTC when serializing time values. This is consistent with how incremental times actually work and produces the least surprise when debugging data values later. However, since the syntax allows it, other offsets, even ridiculous ones (-23:42 ??), may be generated. The offset only matters when parsing the time value--it says nothing whatsoever about the time zone of the value. The time value represented is still an incremental time value.

For some types of time value ("month", "duration"), the time zone provides information on how the time value is interpreted, particularly with computing using incremental time. It also says how to present the time value (heretofore the only time zone available was "whatever the user agent's time zone is", which is inaccessible to the server/page author).

Addison

Received on Friday, 15 August 2014 16:05:29 UTC