-
You are not recreating the issue.
The only way I can think to do so is to do process times on their own instead of with their dates. You shouldn't be doing that as it would calculate using today's date, which would be wrong.
To be fair I am not trying to create the issue, I am trying to demonstrate code that avoids it.
Does this illustrate better? http://jsfiddle.net/aLd28fas/29/
That fiddle sets two datetimes, one in BST and one GMT, it converts them to UTC. let's pretend during that time the utc times get set to a server. Then lets imagine the server returns those utc dates. Now the JS creates two new dates, this time specifying UTC as the input format, and then renders the event times in local time.No matter what my system clock is set to, no matter what date, forward or back, BST or GMT, the result is always consistent and always the correct time for the given date.
What your computer clock is set to is not relevant. The GMT/BST offset is calculated using your computer's DST rules for your locale, but using the date provided, not your clock.
So
If you save 10am BST in UTC you get 9am.
True, and you specify it's BST by providing a BST event date.
If you render UTC 9am and your system clock is presently BST you get 10am.
If you render UTC 9am and your system clock is presently GMT you get 9am.False. Only if you don't provide a date. You should always provide the event date. You get 10am if the provided date is BST and 9am if the provided date is GMT.
So if you create an event destined for GMT (i.e. in the future) today whilst you are in BST, then once DST takes effect, the event will be one hour out.
False. It will be the right time if you use the event date and time when converting to UTC and use the event date and time again when converting back from UTC. Your system clock has nothing to do with it. (As long as your timezone and DST settings are correct: turning off auto DST and then specifying a BST date will result in the wrong input as it thinks it needs to convert from GMT)
The edge case is merely those events created/edited under one DST when the event takes place in a different DST.
Hopefully my latest JSFiddle proves that the creation date doesn't matter, it's the event date that matters.
You are reading a single comment by @Velocio and its replies.
Click here to read the full conversation.
bq
@Velocio
You are not recreating the issue.
You would need to change your system clock to do so given the jsfiddles you've created.
If you save 10am BST in UTC you get 9am.
If you render UTC 9am and your system clock is presently BST you get 10am.
If you render UTC 9am and your system clock is presently GMT you get 9am.
So if you create an event destined for GMT (i.e. in the future) today whilst you are in BST, then once DST takes effect, the event will be one hour out.
None of your jsfiddles disprove that, and everything you describe is already what we do.
The edge case is merely those events created/edited under one DST when the event takes place in a different DST.
There isn't an issue if you create an event a year in advance, but only when the creation/editing of the event and occurrence of the event span a DST change.
Do you understand the problem? I think until now you have not... but I've explained it in several different ways now.