-
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.
Emyr-
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
Dates on events now work across timezone boundaries.
So if you are in Portland and create an event for 11pm, and then access the site from London, it will show correctly as being at 6am, and if edited from France and then you fly back to Portland, the time will show 11pm there as expected.
Basically... we store UTC, and we return HTML containing UTC, but the display and forms use JavaScript to take the local browser setting, so that it always show the time according to whatever your browser locale is.