Global Time Management

Caché, Ensemble

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
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RCOS_fzdatetime#RCOS_fzdatetime_dformat

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

If it's just a log It could be acceptable. If you think on TaskManager starting processes with
a specified time distance to each other this would eventually cause some trouble.

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.

Next: Your calendar server has a shadow backup in a different time zone.

Now you may have up  5 different local timestamps:
- server time
- backup time
- your local time
- your home time
- your customers local time.  

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)wink
you will see time issues faster than you would like or expect.

 

Comments

BTW. cconsole.log does NOT write UTC but local time ($HOROLOG)
I know of no way to influence this.

Any idea ?

One caveat is for future events, especially those that repeat; e.g., I usually eat lunch at around noon local time, regardless of time zone or DST.

I used to have a weekly event in Google Calendar that would be off by an hour after a DST transition.

Hi Robert,

Thanks for reminding about $ZDATETIME and $ZDATETIMEH control parameter -3.

As to which time, local or UTC, is better to use for scheduling and logging, it seems that it depends on app's needs. You provided the sample of calendar server, while many of us can provide the samples when local time is a better choice. Here are mine, both from real life (just simplified a bit).

1) Several similar systems are deployed at different data centers (in different time zones).  99% of each system's users reside in one TZ regardless of where their data center is placed. To minimize performance impact, all service tasks such as backup are usually scheduled nightly. So, OS local time should be set to users' TZ (regardless of the server geographical placement), and nigtly backup should run, say, at 2:00 local time, not UTC.

2) A doctor of Russian football club comes to Spain with his team. When he connects to their EHR server, he views all medical records in his club's domestic local time (UTC+3), and it seems right: if a sportsman was getting some medication at 8:00, he should continue at the same time regardless of TZ where he currently resides (this sample is very similar to Jon's one with lunch time).

Alex,

I like your example #1. The point is to have a COMMON time base. Any is right. UTC is just the most obvious with special conversion.

#2 is the other variant to stay with local home time.