This is just as much for future reference for ourselves as an explanation of the current state of time zone handling in MDriven Turnkey.

UTC - Coordinated Universal Time

• The world is divided into time zones – GMT or PST, etc - some hours.
• The “some hours” change depending on the time of year due to daylight-saving strategies applied by users of different time zones.
• Browsers come in many flavors and each browser implements JavaScript slightly differently.

JavaScript Date type is built to handle the time zone the executing browser is perceived to be in. This means if you enter 2015-01-01 in a browser that resides in Sweden - plus 1 hour (in January anyway) – and then send back the value to the server for storage in UTC – you will store 2014-12-31 23:00. Most developers would say this was less than perfect…

Currently, our take on this is that it is wrong in most cases.

I am not saying time zones are unnecessary and should be ignored. I am merely suggesting that in 99% percent of all systems I have been involved in, dates and times should be handled just as the user entered them. Times and Dates should move around in the system – from the front end to the back end and to and from the database without being inspected from different angles or time zones.

Although time zones are important, there will almost always be some other data in the model that explains what and why that time zone should be used.

Scenarios:

#1 Connecting flights are always shown in the local airport time (where the connection is). The fact that it is the airport that has a time zone and not the browser in this case must be clear. Hence, the location of the airport should be what controls the time zone – not the location of the browser entering or reading the information.

#2 I want to tell everyone that I will start my webcast at noon tomorrow (2015-08-03 12:00:00.000 GMT+2). This would be handy to enter as just “2015-08-03 12:00” in my browser-based publishing application – granted! If friends in Korea want to follow along, they should see: 2015-08-03 19:00. This is a scenario where the current auto adaption of the JavaScript time zone sort of works. I say sort of – because I must be in the correct time zone when I am writing it!!! If I was traveling and needed to enter this date and time while I was in London, my browser-based app would accept “2015-08-03 12:00” – but that is really 2015-08-03 13:00 in Stockholm and 2015-08-03 11:00 in UTC. Even in this great scenario, I would like to be a bit more specific and TELL THE APPLICATION WHAT TIME ZONE I AM REFERRING TO!

While trying to get my head around these issues, I have found tons of stack overflow posts that suggest we use d.getTimezoneOffset() and compensate for the time zone issues – no problem! Well, if I enter a summer date in the winter time, it will be 1 hour off if I am in a time zone that uses daylight saving… What a show-stopper!

This is what we have done

We have MDriven Turnkey times and dates in UTC in the database – stream them in UTC to the angular application. Trick JavaScript into believing that the UTC that comes in really is in the local time zone so that it does not convert the value before display. When the JavaScript code updates a DateTime, it will treat it as if it was expressed in UTC and not in the local time zone then send back the value in UTC format to the server.

• This solution makes more sense to me right now and things stop being strange – like having odd values in the database just because the time was entered in a browser that happened to be in a +X time zone.