In this article I'd like to underline the importance of using UTC timestamps across your
Systems and Applications. Especially if you are developing applications with global scope.
Those of you working in ENSEMBLE will know that any timestamp there is saved as UTC time.
Others may have seen that the conversion functions $ZDATETIME and $ZDATETIMEH have a
control parameter -3 that acts quite different to the rest as it converts one $HOROLOG formatted
string to another $HOROLOG formatted string. One is the local time the other UTC
UTC stands for "Universal Time Coordinated" and is quite often named by the old GMT.
Though the time in Greenwich follows the rules of British Daylight Saving Time.
UTC doesn't do this and gives you a monotonic growing continuous series of values.
So switching from or to Daylight Saving Time is already the first reason to stay away from
local time for calculations. In case you run a log on your backups that normally my take 20 minutes.
If you are lucky to just pass the switching point in March your backup log shows 80 minutes duration.
Not nice. But over the switch to Winter Time it's totally odd showing -40 minutes.
The application where I was confronted with that issue was a calendar at a single server with
global distributed users. The issue was to synchronize appointments across different time
zones and show the appropriate time to all participants in their time zone.
As this was (at that time) ZEN based the obvious approach was to ask the browser for its local
time zone at login. And those users not logged in had their default time zone. No big magic.
BUT let's have this story:
You plan a telephone call with your customer. At the time of the planned call you have
traveled to Global Summit at some nice and warm place far away from home in a different time zone.
The expectation is to get your reminder in time.
This required a temporary time offset from the default home time for adjustment.
Mix it with time zones and daylight saving rules could easily end up in a big chaos if you use
anything else than UTC as the only valid stored timestamp.
I'm sure engineers living in large countries expanding across multiple time zones know it,
but especially Europeans require the advice to think about. If your company or your
customer is expanding on a global base (by successful using InterSystems' products)
you will see time issues faster than you would like or expect.