Hacker News Reader

Comment by bhousel | Hacker News Reader

Why? A few lines of Javascript can tell you which timezone the user's machine is set to. Add a timezone dropdown field to the form where they enter the meeting details, and default that field to their local timezone, but let them change it. Javascript can also tell you whether the meeting date that they picked occurs during DST or not (in the local timezone), store that information in a hidden field.

Now you have everything you need to schedule the meetings and make them appear correctly for everyone involved: The date and time of the meeting, the timezone of the meeting, whether or not DST is occurring there at that date and time. Store everything in the database separately, and store all datetimes at UTC.

This is the solution I built once for an "enterprise" client†, and it worked pretty well.

† a global lawfirm, who regularly needs to schedule meetings across timezones.

View on HN

A few lines of Javascript can tell you which timezone the user's machine is set to.

That is simply not true. You can get the localized timezone as provided by the user's operating system. You would need a server side mapping of every time zone in language for both Olson and Windows. Even then, there are ambiguous timezone names, etc.

The best you can do reasonably is calculate GMT offset, presence of daylight savings time, and if DST is present, then which hemisphere the user is in. From there, you can guess at a city/region with the largest population.

See here: https://bitbucket.org/pellepim/jstimezonedetect/overview

Apologies for not being precise enough (I actually posted that same link in a response below).

With Javascript you can get the user's GMT offset and DST observance. You can't get the political name of the timezone or precise mapping to Olsen database. But for the purposes of scheduling meetings, what you get with Javascript is fine.

Were those recurring meetings or one-offs?

Part of a product I'm working on now is being able to schedule repeating tasks every day, every month, etc. Which means that "07:30 every Friday" has to happen at 07:30 in the author's timezone, whether or not DST is active. To my knowledge Javascript can only tell you the timezone offset from UTC for a given date/time. You can determine the DST-less offset that way, but there are multiple timezones sharing the same offset (e.g. PHP has 63 separate timezone records for Europe alone) and then simply matching them by offsets doesn't work ideally, you need the user to make a choice.

They were one-off meetings, but I think we could have done recurring meetings with the data that we were storing.

I see what you mean about the different timezones in PHP - these are based off the Olsen timezone database. I do think the best way to make users happy is to let them pick their default timezone on a personalization screen, and display it (but let them change it) along with each event that they create.

This Javascript code below can get you most of the way there, but it does come with the caveat that "Not all Olson tz keys are given by this script. If there are many timezones with UTC+6 but none of them use daylight savings, this script simply returns ONE of the timezone keys representing this type of timezones."

https://bitbucket.org/pellepim/jstimezonedetect/wiki/Home

Reply on news.ycombinator.com