You should send the number of milliseconds since epoch (1 Jan 1970 UTC) that is available via the +
prefix operator as in +new Date(2012, 0, 1)
.
Sending anything with a timezone requires both machines to have the same timezone definitions which means you will likely end up with subtle bugs where two dates occurred in one order on one machine but in a different order on another. You can eliminate that whole class of bugs by using the millis since epoch representation.
To answer your questions:
Is this format standard across all browsers?
Date.prototype.toString
and toUTCString
are both implementation dependent but toISOString
is reliable.
http://es5.github.com/#x15.9.5.43
15.9.5.43 Date.prototype.toISOString ( )
# Ⓣ Ⓡ
This function returns a String value represent the instance in time represented by this Date object. The format of the String is the Date Time string format defined in 15.9.1.15. All fields are present in the String. The time zone is always UTC, denoted by the suffix Z. If the time value of this object is not a finite Number a RangeError exception is thrown.
15.9.1.15 Date Time String Format # Ⓣ Ⓔ Ⓑ
ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ
Whereas http://es5.github.com/#x15.9.5.2 says
15.9.5.2 Date.prototype.toString ( )
# Ⓣ Ⓡ
This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the Date in the current time zone in a convenient, human-readable form.
http://es5.github.com/#x15.9.1.15
15.9.5.42 Date.prototype.toUTCString ( )
# Ⓣ Ⓡ
This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the Date in a convenient, human-readable form in UTC.
NOTE The intent is to produce a String representation of a date that is more readable than the format specified in 15.9.1.15. It is not essential that the chosen format be unambiguous or easily machine parsable. If an implementation does not have a preferred human-readable format it is recommended to use the format defined in 15.9.1.15 but with a space rather than a “T” used to separate the date and time elements.