-
If you have a database that maps lat:lon to timezones and keeps them up to date across daylight savings, and applies to the whole world... then sell it, because no-one else has a truly accurate database like this. The best timezone one is within the Linux world, but isn't coupled with a full lat:lon database, just city relationships to timezones.
Device clocks are actually a damn good guide, all mobile devices update their clock from the network when crossing borders nowadays, and people who travel that much do change their laptop clock as you're usually doing meetings and researching local time-based stuff.
So it works, and it works well.
There is a catch though... with what I've done. Whilst it's very natural and involves no config, it doesn't know about changes to daylight savings.
So if you create an event that is on Monday 27th October, and it's presently Saturday 25th October, and you created it to start at noon, it would be saved as 11am UTC. After the clock changes on the 26th October it would display as 11am GMT.
This is technically correct as the UTC representation didn't change... but it's obviously flawed as it should know that the event date on the 27th was noon GMT and should be saved as noon UTC.
The problem I have is that if I fix that (and I could with some effort... an API call to a time database asking what the time will be on some specified date within a specific timezone - no location info though)... then the event would save showing the time as 1pm BST, and the vast majority of people creating and editing events would consider that to be a bug. They think simple and just want to say "Noon" and we'd change it to 1pm BST/Noon GMT and they'd freak out and change it back. And I could show the time twice, but this would greatly confuse them.
Basically an edge-case is the clock changes, but I have no elegant solution that people would not treat as a bug either way.
Velocio-
I shall try and be helpful. This might not work for you, but I used to solve those sorts of problems for Bookatable, so this might help.
Storing date times as UTC (or milliseconds since epoch) is absolutely the right approach. Trying to store and calculate time zone and DST offsets on a server is a descent into madness. Keep the server in a known state and treat the client as accurate.
If the user created the event for a time after DST ends but creates it while DST is in place, well it doesn't matter. Have the client send a datetime as milliseconds since epoch or as UTC. and it ought to be accurate for the event. If you do need the Timezoneoffset offset then JS can send it. If you need to know whether DST is in play then you can compare it with a new date at the same time, but the month set to January, which won't be DST anywhere. If there's an hour's difference it's DST.
This ought to be enough to render it on the client with the correct date and time for the event on the server, but for extra peace of mind send it to the client in UTC or epoch and use JS to display it in the user's local time. It should be accurate then, no matter what.
bq
Proposal:
When editing, if a location is chosen, treat the time input as location-local. Ignore browser locale.
When displaying, if the location is in the same timezone as browser locale, show local time, otherwise show both location-zoned time and browser-locale-zoned time.