-
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-
It does.
But if you create an event on the Saturday 25th October for 10pm in London, the UTC is 9pm.
If you view the event on Monday 27th October the UTC is still 9pm and as no DST now applies the local event time will be shown as 9pm.My point is that someone intended it to be 10pm, and it now says 9pm. I've stored the right value given their input, but it's the wrong value given their intent (the event is at 10pm, which is what they chose in the drop-downs, they meant to store 10pm UTC).
And if I made sense of this, it would mean showing 11pm BST on Saturday 25th, so that 10pm GMT was the event time... but most users would regard that as a bug... users don't think of DST.
Velocio
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.