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?

The problem is described in our document on working with timezones:

   http://www.w3.org/TR/timezone/#floatingevents

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: [http://www.w3.org/TR/timezone]

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.

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.

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.

It's simple enough to demonstrate.

---

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

}
</script>

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

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:

   http://www.inter-locale.com/test/DateDemo.html 

That's because JavaScript 'Date' is an incremental time (it's actually a long value).

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.

Turn a "date" field into a "Date" object and then display the resulting value? Really?

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.