You are reading a single comment by @Velocio and its replies. Click here to read the full conversation.
  • 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?

  • 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.

About

Avatar for Velocio @Velocio started