timezone offset in javascript display

Question

I'm running into what seems to be a common problem of using a javascript datepicker to display and allow users to select dates from a calendar of available schedule dates for room reservations.

The browser's timezone conversion means that these dates are always off by some margin, so that often when displaying a reserved date to the user, the date will fall on "tomorrow" to the viewer, when the server (the timezone local to the asset or room as stored in the DB) shows them as "today".

I would like the user's browser to ignore the javascript date conversion and just use the actual datetime that is passed in by the database.

However, this even happens on a really simple example like this:

var date = '2013-02-05';

var newdate = new Date(date);

console.log(newdate); // Mon Feb 04 2013 16:00:00 GMT-0800 (PST) 

It appears that the date variable is assumed by the browser to be GMT, and when I create a javascript date object from it, it converts that GMT time to my local time.

Is the best practice in this case to use GMT dates in the database, and set the site's local time offset as a variable in the javascript, which can then be used to offset the dates displayed to the end user, and again offset the dates received from the end user for insertion into the database?

This is confusing since there's so many potential pitfalls-- the PHP locale, mysql locale, or browser's locale could all factor into it and mess up the final date. Any advice on ensuring a consistent date value appreciated!

Answer 1

Good question, handling timezones is a mess. Fortunately Javascript has UTC variants of most of its methods. See http://en.wikipedia.org/wiki/Coordinated_Universal_Time

I think the best is to use UTC dates everywhere (except UI maybe ). Make sure that server uses and stores UTC dates, and use the javascript UTC methods everywhere. That's the first and most important step, so you know the dates are consistent.

How you present dates in UI is lot less straightforward, and kind of depends on the target audience, application nature etc. I think that's more a subject of discussion, and kind of unanswerable in Stack Overflow (there are other forums for subjective pondering).

I'd say don't trust browser or any kind of geolocation to autoconvert timezones; it should be user configurable, or maybe group/project/install specific setting. Some software are mainly used inside one timezone, and trying to automatically convert timezones might be confusing and annoying for users, if they are used to communicate in some "standard" time. Should user see times in different timezone if he or she is travelling? Sometimes it makes sense, sometimes not, but at least make sure the user knows what logic you are following, both when reading and inputting times.

I develop project management software where it's important these things are handled unambiguously bot by the application, and by users (!). My approach is to always force UTC both for display and input. It's also clearly visible in each date that it is UTC. Handling a variety of timezones would get hairy quick, and I decided it's better to just not do that. I have some helpers in parts of the UI that show the same info in users local timezone etc in fine print. There is a project-wide setting to "hide all timezone-related stuff, and force timezone x", that can be used in smaller projects that are known to never cross timezone boundaries, there is an agreement to use certain zone, or it's just a given and its better to not bother users with that kind of complexity.

EDIT: I should add that, as an example how hairy this can get, sometimes a time is only a time. In some contexts, an event at 15:00 could mean it happens at 15:00 at different places, at their respective local timezones. Uhh....