3

I store dates on server side in UTC timezone. When client (browser) wants to pass some date to server it sends date like

"Tue Jan 03 2012 16:50:32 GMT+0400 (Russian Standard Time)"
  1. Is this format standard across all browsers?
  2. If 1. is false, how can I redefine the Date format function? Is this a good practice?
  3. How can I convert JS Dates to a UTC java.util.Date with java.text.SimpleDateFormat?

UPDATE

I thought that passing date as formatted string (with timezone part) will cause less headache since I shouldn't bother to convert dates to UTC on client side. So I avoid any date conversions in JS code.

Mike Samuel
  • 118,113
  • 30
  • 216
  • 245
Plastic Rabbit
  • 2,859
  • 4
  • 25
  • 27

3 Answers3

4

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.

Community
  • 1
  • 1
Mike Samuel
  • 118,113
  • 30
  • 216
  • 245
2

I don't know whether this format is standardized for all browsers.

But you could use the getTime() function in JavaScript which returns the milliseconds since 1 January 1970 00:00:00 UTC and initializes the Java Date object with this value.

ComFreek
  • 29,044
  • 18
  • 104
  • 156
  • I'm afraid that javascript .getTime() returns value with current timezone adjustment. – Plastic Rabbit Jan 03 '12 at 13:16
  • @PlasticRabbit: It shouldn't... when you say you're "afraid" do you mean that you fear the documentation may be incorrect, or you've tried it and seen the wrong values? – Jon Skeet Jan 03 '12 at 13:22
1

You could send the data in UNIX time format, maybe?

Gaurav Gupta
  • 5,380
  • 2
  • 29
  • 36