-
That is what I have done.
Client sends UTC to server, that's what we save.
We send UTC to client, and client renders local time.The only additional thing I could do is to ask the user at the time of creating the event which timezone the event occurs within. Namely, to ask which IANA Time Zone location ( http://www.iana.org/time-zones ) i.e. America/New_York , that the event occurs within. This would allow me to determine precisely when DST starts/ends (if it applies at all) and would allow me to represent the correct date and time even through the DST changes.
I can't use an event lat:lon to do a nearest city, as a border location may return the wrong location.
And the big concern I have with this is that only *nix systems have this deep knowledge of timezones, and so whilst we are prepping to open source the code base we would have introduced the first thing that made it system specific.
I also note that Google Maps API includes a lat:lon overlay to the IANA Time Zone database ( https://developers.google.com/maps/documentation/timezone/ ), so that might be possible too. That looks like a good answer, but I still have the issue of whether I display the adjusted time stamp pre-DST for an event post-DST and vice versa... not doing so is more intuitive but incorrect, and doing so is correct but unintuitive.
I'm basically settling for leaving this and figuring out how much of a problem the edge case is later.
Velocio-
This shouldn't be a problem then.
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.
The JS should give you the right UTC for the event date and time, not the current date and time and vice versa.
bq
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.