This project has moved. For the latest updates, please go here.

Date parsing - doesn't like millsecond portion

May 15, 2013 at 12:46 AM
I am trying to parse a date string into a Date object.

This works: 1/1/2013 13:59:05
This doesn't: 1/1/2013 13:59:05.123
var d = new Date("1/1/2013 13:59:05.123");
var invalid = (d == null || isNaN(d.getHours()));
// invalid == true
May 15, 2013 at 2:47 AM
Edited May 15, 2013 at 4:31 AM
Correct, Jurassic doesn't support this type of date string (unstructured, with milliseconds). A quick check reveals that Chrome supports it in their javascript implementation, but Firefox and IE don't.

This is the equivalent ECMAScript standard date string, which works in all browsers (and Jurassic):
new Date("2013-01-01T13:59:05.123")
May 15, 2013 at 4:59 PM
Thanks. I wound up implementing the millisecond parsing for unstructured dates in our Jurassic build (in DateParser). The problem is I can't use ECMA string because they parse to UTC, and in our app we use relative time strings based the current user time zone among other things.
May 16, 2013 at 12:18 AM
The example I provided does parse to a local time -- in Jurassic -- but it turns out this is a standard violation; ECMAScript 5.1 says that a missing time-zone should be interpreted as UTC. There is actually no standards-compliant way of parsing a local date & time, without explicitly specifying the time-zone (e.g. "2013-01-01T13:59:05.123+13:00"). In my defence, IE 10 and Firefox 21 both get this wrong (presumably because the local time-zone defaulting behaviour is more useful). Also, the ECMAScript standard conflicts with ISO 8601 which says that the absence of a time-zone should be interpreted as the local time-zone. Standards are great, huh?