This is just as much for future reference to our selves as an explanation of current state of time zone handling in MDriven Turnkey.
UTC - Coordinated Universal Time
The world is divided into time zones – GMT + or – Some hours.
The “Some hours” change depending on time of year due to daylight saving strategies applied by users of different time zones.
Browsers come in many flavors – browsers implement JavaScript slightly different.
JavaScript Date type is built to handle the time zone the executing browser is perceived to be in.
This means that 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. This is what most developers would say was less than perfect…
And currently our take on this is that it is wrong in most of all cases.
Ok – I do not say that time zones are unnecessary and should be ignored – I just say that in 99% percent of all systems that 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 front end to backend and to and from database without being inspected from different angles or time zones.
When 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 always show up 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 should the location of the airport 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 web cast 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! And if friends in Korea want to follow they should see : 2015-08-03 19:00. This is scenario where the current auto adaption of JavaScript time zone sort of work. I say sort of – because I must be in the correct time zone when I am writing it!!! If I was travelling 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. So even in this good scenario I would actually like to be a bit more specific and TELL THE APPLICATION WHAT TIME ZONE I REFER TO!
When I have been trying to get my head around these issues I have found tons of stackoverflow posts that state that we can just use d.getTimezoneOffset() and compensate for time zone stuff – no problemo! Well – if I enter a summer date in winter time it will be 1 hour off if I am in a time zone that use daylight saving… Show stopper!
This is what we have done: Have MDriven Turnkey times and dates in UTC in the database – stream them in UTC to the angular application. Trick JavaScript to believe that the UTC that comes in really is in local time zone – so that it does not convert the value before display. When the JavaScript code updates a datetime – treat it as if it was expressed in UTC and not in local time zone – then send back the value in UTC format to the server.
This solution makes most sense to me right now and things stop to be 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.