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.
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
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:
Date(long date) constructor and
Date constructor. There should be no other timezone involved than Coordinated Universal Time (GMT/UTC).