Documentation:Time zones and sanity–post for future reference

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.