Subtle changes, bugs and feedback

It's been a year or two since I was immersed in this, but I don't think that's right.

But if you create an event on the Saturday 25th October for 10pm in London, the UTC is 9pm.

True.

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.

This ought to be false if you are using the right JS to convert back to a string and display it. The JS will display the 25th event as 10 because your system knows that on the 25th DST was in play.
See this JSFiddle for proof.
http:/jsfiddle.net/aLd28fas/16/

Your jsfiddle cheats.

var bst = new Date(2014,9,25,10,00,00);
var gmt = new Date(2014,9,27,10,00,00);

That is not representative of the system.

If you store the UTC value of the BST date on the 25th... and then render that value on the 27th, what time is displayed?

So, specifically pass in a UTC value?
Please hold...

So if you do the BST > UTC calculation in the client and store that the result is the same. As long as you tell the constructor you are passing in UTC.

See http:/jsfiddle.net/aLd28fas/18/

There are UTC analogues of everything if you need them.

I'd do it like:
To store: user enters event date and time. JS assumes locale time is being specified, and uses standard constructor to create date object. Pass into server as UTC using UTC output methods to format as required.
To display: server passes back UTC, JS uses UTC constructor to create date object, displays dates using normal output methods to show correct local times. At no point have you needed to care about DST.

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.

The legend that is Robin Johnson came up with a solution to this without ever using a computer. Since he has been running the Mitre end of season 25* on the Sunday after clock change every year for about 40 years, he just puts a note on the start sheet to remind people to allow for the clock change :-)

*Still time to get your entries in, lots of prize categories including fixed

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.

Ah, I see where the confusion is.

I'll update when I get back, but in essence I don't know which timezone an event occurs in and may not know where it occurs either.

Anyhow, my earlier statements are all true, yours are only true if there is an implicit assumption in the mix... which is a false assumption.

Key points:

1. We do not know the timezone of the event.
   
2. We may not know the location of the event.
   
3. The event location may never be filled in (it is not a required field).
   
   

So during event creation we ask "When is the event", and someone might say "10pm on such and such a date". When we save this, we ask their browser to tell us when the event starting date is in UTC... so their browser does the conversion here and if they were in California, it would correctly convert the 10pm time to the UTC. And of course, absolutely of course, we store the full date + time stamp in UTC... so the UTC day may actually be a day earlier or later depending on where you are in the world, your timezone, when you do this.

That bit is super-simple... we never asked your timezone, we never cared where the event was, we used your browser to tell us the UTC of the start time of the event.

We also do not store time and date separately, and we don't store an end date either (we store an event duration in minutes instead).

So, for an event, we store a single UTC value, with no timezone information at all. And the value we store was told to us by your browser, and we do not (or may not) have any location information to go along with the event and did not ask for or save any additional timezone information.

Now... now do you see why there is an edge case?

OK, so when someone creates an event, you instantiate a JS Date object with the date and time they fill in, their browser does the UTC conversion, and you store that along with a duration in minutes. Their browser does that conversion based on the timezone they are in and the DST state that the event will occur in. You should get the correct UTC datetime.

I come along and look at the event in London, and the server sends the UTC datetime, yes?
My browser displays the date and time of the event in my local time, which it will calculate according to my timezone, and the DST state at the time of the event. I should get the correct time.

So where is this edge case? Why do you think that you need to store timezone info or event location? I think you're overcomplicating it. Why don't you just come out and tell me what you think I have missed?

OK, so when someone creates an event, you instantiate a JS Date object with the date and time they fill in, their browser does the UTC conversion, and you store that along with a duration in minutes. Their browser does that conversion based on the timezone they are in and the DST state that the event will occur in.

The bolded bit is the assumption.

That does NOT happen.

It could only happen if we either:
a. Ask what timezone the event occurs in.
b. Know where the event occurs.

(b) isn't always true, and we don't ask (a).

Why u no understand?

Look, if you want a proof... create an event today, and wait three weeks.

My browser displays the date and time of the event in my local time, which it will calculate according to my timezone, and the DST state at the time of the event.

Oh, and this will work inconsistently across browsers.

Because the JavaScript is asking the question of their OS, and unless you're on a recent *nix the answer will vary, especially if it's an older OS and hasn't been updated... for example not all versions of Windows know that the USA extended their daylight savings.

There is no JavaScript API for "isDST()"... the best you can do is ask the browser to generate dates at different times of the year and then see whether the timezone offset of those dates differ. But, as I've already pointed out... the browser is asking this of the system and the system likely does not know.

Only *nix systems have the IANA Time Zone database... it's under /usr/lib/zoneinfo or /usr/share/zoneinfo .

Other systems, incredibly, just have whatever subset was shipped.

Why do you think this doesn't happen?
It does. It's not an assumption. I wrote the JSFiddle code to prove that it does.

Did you not see that with your browser? It did it in Chrome on Windows 7. If you didn't see that then check your timezone and DST settings.
I instantiated two dates, one for a date in BST and one for a date in GMT and it correctly converted to UTC for each.

If you instantiate a JS Date object with a new Date(year, month, day, hours, minutes) then it will use your local OS's timezone and DST information.

Argh! Doing my head in.

1. Do you accept that if you save 10am BST in UTC you get 9am?
   
2. Do you accept that if you render UTC 9am and your system clock is presently BST you get 10am?
   
3. Do you accept that if you render UTC 9am and your system clock is presently GMT you get 9am?
   
   

There are no other assumptions in the questions, no hidden information, nothing more to know... just those things. No ifs, no buts. Don't assume anything else, each question is the totality of information you have, and there is nothing more than what is stated in each question.

#1 Happens when they create an event.
#2 Happens when they view the event immediately after creating it.
#3 Happens when they view the same event in 3 weeks time, after DST has changed.

This is why my zany pilot sitcom about two computer geeks living together never got picked up.

I love it when they talk sexy date time.

Yes, yes and yes.
But, ONLY if I instantiate Date object with Today, then ONLY setting the time before converting from UTC to local.

If you're truly only passing the time to your Date object then you're doing it wrong and of course your code will fail. If you instigate that date object with the event date and time then your system clock is NOT relevant. It is the event date that decides whether it converts to BST or GMT

Yes, yes and yes.

Then you have accepted my point wholly, and I have no idea what you are going on about.

Perhaps trying metric instead of imperial would work?

My understanding, and what I believe VB undestands the behaviour to be...

When you instantiate a DateTime event with both date and time, the zone of the browser at the point of instantiation is used, not the zone for that locale on the given date.

Otherwise, how do you handle 2am events?

Exactly that.

We don't ask for timezone or daylight savings info about the when, and we may not have a where... so we imply that the timezone offset is the same as the user creating/editing the event.

Please let us opt out of @ notifications as soon as possible so we can escape the madness of getting two notifications for the same post.

1 Attachment