- From: <bugzilla@jessica.w3.org>
- Date: Tue, 18 Sep 2012 15:21:57 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16960 --- Comment #3 from Addison Phillips <addison@lab126.com> 2012-09-18 15:21:56 UTC --- The I18N WG would like you to consider several ways of addressing the issues raised by the 'local date and time' microsyntax. One way of addressing it would be to define it in terms of a floating time value, although floating times are usually either a date (with no hour/minute/second value) representing an event such as a birthdate that is not ties to a specific time zone or to a time (with no day/month/year) which can be interpreted as a local wall time in any time zone (such as the time of day to observe the DST transition), rather than a combination of both. Another would be to mention the problem of time zones and allow implementations to tie the value to a specific arbitrary time zone (probably UTC) when comparing/converting to/from incremental time values. For example, ECMAScript Date values are incremental times (millis since epoch) and the relationship between 'local date and time' and this type of incremental time should be clear. Note that if this were the case, the name of the microsyntax would be misleading. It's not a 'local date and time' unless it somehow corresponds to local wall time, is it? But if it corresponds to local wall time, then it inherently has a time zone which is most probably not UTC. In that case, the time zone should be explicit and explicitly available. I am aware that this microsyntax is not an invention of HTML5, but the I18N WG is concerned that the definitions provided make it too easy to create forms and pages that don't handle time values correctly or which change time values in subtle but quite broken ways. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 18 September 2012 15:22:09 UTC