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 14890 - For invalid Date, the terminology here seems to be "undefined" insted of "null" according to WebIDL, and the ECMAScript "null" value should never reach here according to the IDL description of attribute "valueAsDate". For readiblity, I suggest we just s/i
Summary: For invalid Date, the terminology here seems to be "undefined" insted of "nul...
Status: RESOLVED FIXED
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
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-20 21:14 UTC by contributor
Modified: 2012-07-18 18:47 UTC (History)
3 users (show)

See Also:

Attachments

Description contributor 2011-11-20 21:14:02 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html
Multipage: http://www.whatwg.org/C#dom-input-valueasdate
Complete: http://www.whatwg.org/c#dom-input-valueasdate

Comment:
For invalid Date, the terminology here seems to be "undefined" insted of
"null" according to WebIDL, and the ECMAScript "null" value should never reach
here according to the IDL description of attribute "valueAsDate". For
readiblity, I suggest we just s/if the new value is null/if the new value is
the invalid Date/.

Posted from: 114.43.114.197 by kennyluck@csail.mit.edu
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20100101 Firefox/8.0
Comment 1 Ian 'Hixie' Hickson 2011-12-07 23:42:27 UTC 
Come again?
Comment 2 Ian 'Hixie' Hickson 2011-12-09 22:20:29 UTC 
I think the problem here was just that valueAsDate wasn't marked as nullable, but I'm not sure.
Comment 3 Kang-Hao (Kenny) Lu 2011-12-15 05:16:36 UTC 
Apparently my one-liner did't work so let me try again. The main problem is as follows. What should happen if the following script is run?

var input = document.createElement('input');
input.type = "date";
input.value = "2011-12-15";
input.valueAsDate = new Date("hixie"); // invalid date
alert(input.value);

This doesn't seem to be well-defined as various "algorithm to convert a Date object to a string" algorithms seem to miss this case (the 'undefined' Date). For your data, Safari 5.1.1 treats invalid date as if it were null and the result is the empty string. Others pretty much don't have implementations close to this nit.

(In reply to comment #2)
> I think the problem here was just that valueAsDate wasn't marked as nullable,
> but I'm not sure.

I am not sure why null is better than an invalid date (new Date(NaN)), which I originally thought to be a better idea, but I can agree that null is more testable.

(In reply to comment #1)
> Come again?

I don't understand. Could you elaborate?
Comment 4 Ian 'Hixie' Hickson 2012-01-25 23:20:06 UTC 
(new Date("bogus")) is exactly equivalent to (new Date(NaN)).

It's true that the spec didn't define how valueAsDate should handle a Date with a NaN time value. I have now fixed that. Thanks for the bug report!
Comment 5 contributor 2012-01-25 23:20:42 UTC 
Checked in as WHATWG revision r6918.
Check-in comment: Define how valueAsDate's setter should handle a NaN time value.
http://html5.org/tools/web-apps-tracker?from=6917&to=6918