-
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?
bq-
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?
-
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.
Velocio
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:
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?