The native Ecmascript timestamp is: YYY-MM-DDTHH:mm:ss:.sssZ
This (and the alternative versions below) is also the format as expected and accepted by Date.parse(). But note that Date.parse may also accept additional implementation defined formats. See also about extended years in 15.9.1.15.1.
The timestamp is derived from a simplified ISO 8601 Extended Fromat.
The hyphens, colon, T and dot appear literally in the string.
YYYY: the decimal digits of the year in the Gregorian calendar (1987)
MM: month of the year, two digits (01 to 12)
DD: day of the month (01 to 31)
T: again, this is a literal and functions as a seperator between date and time
HH: number of complete hours since midnight of the timestamp, two digits (00 to 24, where 24 is equal to 00)
mm: number of complete minutes since the start of the hour, two digits (00 to 59)
ss: number of complete seconds since the start of the minute, two digits (00 to 60, although 60 is only used to represent a leap second, which don't exist in Ecmascript)
sss: number of complete miliseconds since start of the second, three digits (000 to 999), optional
Z: timezone, optional. Either the literal "UTC" or a "-" or "+" and an expression hh:mm to represent the offsets (usually only in whole hours though). Ex: +01:00.
This format includes date-only and time-only forms, with optionally a timezone appended:
YYYY
YYYY-MM
YYYY-MM-DD
THH:mm
THH:mm:ss
THH:mm:ss.sss
Any combination of the above is also valid (including the optional timezone).
All numbers of a date are base 10, so no hex.
Illegal values (out of bounds, illegal characters) result in no date and the internal value for the date will be NaN.
In this regard, I'm not sure whether the specification would want ss:60 to be invalid or not, since it's technically
valid for ISO 8601, but leap seconds don't exist for Ecma...
Note that there is no standard for time zone strings like CET, EST, etc. Sometimes the same string can mean two zones. That's why they are not supported by the specification.