This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17854 - i18n-ISSUE-85: Health warning about converting date to/from incremental time
Summary: i18n-ISSUE-85: Health warning about converting date to/from incremental time
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
Depends on: 16957
  Show dependency treegraph
Reported: 2012-07-18 07:04 UTC by contributor
Modified: 2013-04-12 23:00 UTC (History)
4 users (show)

See Also:


Description contributor 2012-07-18 07:04:10 UTC
This was was cloned from bug 16957 as part of operation convergence.
Originally filed: 2012-05-07 17:06:00 +0000
Original reporter: Addison Phillips <>

 #0   Addison Phillips                                2012-05-07 17:06:53 +0000 
-------------------------------------------------------------------------------- Dates

The 'date' definition contains no time zone information. It is thus a floating date value and a health warning should be included about converting it to/from incremental time values.

Note that JavaScript is working on an I18N extension that will include time zone support.
Comment 1 Ian 'Hixie' Hickson 2012-09-27 23:30:26 UTC
Could you elaborate on what kind of warning you are looking for here? When would someone who should see this warning see it? What would they be doing?
Comment 2 Addison Phillips 2012-12-29 18:17:41 UTC
The problem is described in our document on working with timezones:

The warning could be something like:

NOTE: 'date' values do not include time zone information. Care is needed when converting fields of this type to or from date data types in JavaScript and other programming languages. In many cases, an implicit time-of-day and time zone are used to create an "incremental time" (an integer value that represents the offset from some arbitrary epoch time). Processing or conversion of these values, particularly across time zones, can change the value of the date itself. See: []
Comment 3 Ian 'Hixie' Hickson 2012-12-30 05:52:53 UTC
Isn't this self-evident? If you convert a data type that corresponds to a twenty-four hour period that doesn't specify a time zone into a data type that corresponds to a single second that does specify a time zone, you're obviously going to have to be careful.

I don't understand who you expect the warning given in comment 2 to help. Anyone who is knowledgable enough to understand that warning is already going to know to not screw it up, and those that aren't are highly unlikely to read the spec, let alone understand the warning enough to make sure they avoid the mistake.
Comment 4 Addison Phillips 2012-12-30 06:38:05 UTC
No. It isn't self evident. Otherwise I wouldn't have to spend a lot of time telling developers about it. This is a common problem because it is rarely talked about and implementers forget that what we call "floating" times can't be converted to incremental time values safely.
Comment 5 Ian 'Hixie' Hickson 2012-12-30 18:35:42 UTC
Could you elaborate on what exactly people are doing? I am having trouble coming up with a viable situation in which you'd take a date-without-timezone and convert it to a second-with-timezone if you don't know the time zone of the day. Do you have any pointers to mailing list posts where you've tried to explain this to authors? I'd love to see what they're saying in response, as that would help me craft text (and figure out where to put that text) to maximise the impact of a warning we put in. I don't think the suggestion in comment 2 would work; I barely understand it, let alone someone who is likely to run into this problem.
Comment 6 Addison Phillips 2013-01-02 18:25:18 UTC
It's simple enough to demonstrate.


<script type="text/javascript">
function showtz() {
   var x=document.getElementById("date");
   var date = new Date(x.value);


<p>Date: <input type="date" id="date" name="date" onchange="showtz()"></input></p>

If you input "2012-10-20" into this form, the alert shown for me (in the America/Los_Angeles time zone) contains:

   Fri Oct 19 2012 17:00:00 GMT-0700 (Pacific Daylight Time)

This is "2012-10-20 GMT", but it is not the "October 20th" that the user expects. The above is implemented in: 

That's because JavaScript 'Date' is an incremental time (it's actually a long value).
Comment 7 Ian 'Hixie' Hickson 2013-01-05 04:05:42 UTC
But why would anyone do that?

Pointers to mailing list posts where you've tried to explain this to authors, and in particular their responses, would be very helpful in my understanding this.
Comment 8 Addison Phillips 2013-01-05 04:35:33 UTC
Turn a "date" field into a "Date" object and then display the resulting value? Really?
Comment 9 Ian 'Hixie' Hickson 2013-03-06 22:36:17 UTC
Without a pointer to mailing list discussions or forum posts or blog discussions or some such with Web devs having this problem, I can't figure out what text would help Web devs.

A "Date" object has hours and minutes. a "date" string does not. I don't understand what sequence of thoughts would lead to one thinking you can go from one to the other without knowing what time zone you're talking about, which is why I'd like to see the kinds of things people say when they do do this.