Java/JavaScript dates: Is this true?

Question

So lets say a user is running my web app from his browser on a different time zone than the application server. I serialize a date on the client-side by using JavaScript's date.getTime() method. I send the resulting milliseconds through Json and then create a Java Date object on the server-side by calling new Date(millisecondsFromJS). I store that on MySql, retrieve it, serialize it again by calling Java's date.getTime() and send it once again to the client through Json.

If I create a JavaScript Date object with those milliseconds, will it result in the original date? I've successfully gone through this process, but the client and server are currently on the same time zone. I'm not sure if the date will get corrupted in the process if the time zones are different.

As I understand it, using getTime() returns an instant in time that is independent of time zones. If the user captured July 17, 2012 at 4:39 PM CDT, the server might store it as July 17, 2012 at 11:39 PM CEST, for example, but once the server converts this to milliseconds since GMT and the client creates a date from these milliseconds, it would have successfully reconstructed the original July 17, 2012 at 4:39 PM CDT. Is this true?

Answer 1

There was some good advice in the article Scaling lessons learned at Dropbox, part 1:

Keep everything in UTC internally! Server times, stuff in the database, etc. This will save lots of headaches, and not just daylight savings time. Some software just doesn’t even handle non-UTC time properly, so don’t do it! We kept a clock on the wall set to UTC. When you want to display times to a user, make the timezone conversion happen at the last second.

---

Send the unix time milliseconds to the server and you know which point of time the user selected. Then handle everything on your server in UTC and return the millisecond integer back to the client.

Client / JavaScript:

var date = new Date();
var clientMilliseconds = date.getTime();
// send clientMilliseconds to server

Server / Java:

Date date = new Date(clientMilliseconds);
// store the date, then get it back
long serverMilliseconds = date.getTime();
// send serverMilliseconds back to client

Client / JavaScript:

var date = new Date(serverMilliseconds);
// If receiving the error "Invalid Date", serverMilliseconds
// needs to be converted to an Integer. Consider:
// parseInt: parseInt(serverMilliseconds, 10)
// unary +:  (+serverMilliseconds)

Along the way, the date objects on the server and on the client will both reflect the respective timezones so if you look at both, they might seem different, but they aren't if you convert them back to UTC using the same timezone.

---

So to answer your question:

If I create a JavaScript Date object with those milliseconds, will it result in the original date?

Yes.

Java's Date(long date) constructor and getTime() method operate with unix time milliseconds. So does JavaScript's getTime() and Date constructor. There should be no other timezone involved than Coordinated Universal Time (GMT/UTC).

Answer 2

There are some issues

• The client is on different timezone. This is not really an issue if you use .getTime(), .valueOf() etc because they use ms since epoch according to UTC.
• The real issue is that the client's clock can be skewed. If someone has set their computer back in time to avoid having to register some programs for example, it will cause the client to generate false timestamps
• They can also have a small amount of skewness just because clocks are inaccurate like that

You can counter this by sending a timestamp from your server and then comparing it to timestamp generated from the client, to get the skewness offset. You'd then apply this skewness offset to all new Date.getTime()s you generate on the client. Though this won't work if the client changes their system time as they are using your page.