My product involves scheduling of reoccurring reminders, deadlines, etc. Handling of timezones in particular has been an incredible productivity black hole.
Side note: Who do I need to pay off to get a Olson timezone header added to the HTTP spec?
Side note: Who do I need to pay off to get a Olson timezone header added to the HTTP spec?
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.
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.
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."
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
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.