Tell me more ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 2 down vote favorite

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?

share|improve this question
 
I think it would be much safer to use a text form of the date that includes the time zone offset the date is relative to. Then, both client and server can know exactly what the time value is regardless of what timezone they reside in. Or, if you want to use milliseconds, then standardize on milliseconds that are GMT milliseconds, not in a local timezone. –  jfriend00 Jul 17 '12 at 21:47
 
Besides that the unix time is in UTC, to get an ISO representation of a date: var now = new Date(); and then now.toISOString(); –  Wolfram Jul 17 '12 at 21:58
 
Java's getTime() milliseconds are GMT, I'm not sure if JavaScript's are though... –  JayPea Jul 17 '12 at 21:59
1  
@JayPea developer.mozilla.org/en/JavaScript/Reference/Global_Objects/… –  Esailija Jul 17 '12 at 22:00

2 Answers

up vote 2 down vote accepted

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);

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).

share|improve this answer
up vote 2 down vote

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.

share|improve this answer
 
Thanks, the second issue you mention is not really a problem in this case, since the date comes from a date picker and is not meant to represent the current point in time. So getTime() from Java and JavaScript will return the same value? –  JayPea Jul 17 '12 at 21:52
 
@JayPea no they won't if the client's system clock is skewed. For example, in stackoverflow chat they genereate a skewness offset of 5.5 seconds for me. –  Esailija Jul 17 '12 at 21:52
 
Something else I though about... If this works, but the server is suddenly moved to another timezone, then when it retrieves the dates from MySql it will apply a different timezone and the user will get wrong dates. –  JayPea Jul 17 '12 at 21:53
1  
@JayPea Operate on timestamps and UTC dates. Also, if you can avoid using timestamps generated on the client, then of course do that. –  Esailija Jul 17 '12 at 21:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.