A date with Date, Time, Duration and Timezones
Have you ever wondered, when debugging an issue in a
globally distributed environment, if the events are out of sequence? Chances
are that all of us would have seen it at least once in our professional career.
All applications are required to deal with Date, Time and Duration.
This is a very complex area, as the rules regarding time-keeping are not widely
known and this causes tricky and funny (and sometimes critical ) issues. Adding
to this is the additional complexity of Time zones (TZ) and the Daylight
Savings! Phew!
Let’s refresh our understanding of how Time zones are arrived at.
Since a day is 24 hours long, the world may be split into 15
degree wide longitudinal slices (360 degrees/24 hours). Each slice represents
one hour. But, life is not so simple. The International Date line creates an
additional TZ and a few TZ’s differ by 30 mins /45 mins.
If Greenwich (0th meridian) has the current local time as 00:00
hrs, then Brussels is approximately one hour ahead of GMT and Praira (capital
of Republic of Cabo Verde) is one hour behind. But GMT itself is a local TZ and
quite a few countries use this as their TZ, then what is the standard?
Enter UTC or the Universal Coordinated Time. The worlds timing
centres, around 70+ of them, maintain the atomic clock and keep it synchronized
(coordinated) and hence the name UTC. (https://www.bipm.org/utils/en/pdf/time_ann_rep/Time_annual_report_2014/11_Table3_TAR14.pdf). UTC is
based on a 24-hour clock and hence is always represented as such with a special
designator Z (standing for Zulu)
An
Example is 2019-07-19T04:53:30Z
When representing local
times, the strings +hh:mm, +hhmm, or +hh or -hh:mm,
-hhmm, or -hh can be suffixed to the time to indicate that the used
local time zone is hh hours and mm minutes ahead/behind of UTC respectively.
Now since we have enough background
into the Time, let's delve into the various scenarios that we may encounter
1. Applications
are deployed in different TZ and the servers are configured with local TZ. The
date/time data captured is of that TZ where its deployed
2. Applications
are deployed in different TZ, but the database is a central one and there is a
column in a table that takes the current system time of the operating system on
which the database resides, and if that is a local time, then its captured
3. Applications
are accessed in different TZ and hence the capturing of input from users’ on
client TZ
4. Say we
are transferring data or backing up and restoring in different TZ’s
As we can see, there could
be various permutations and combinations that could result in the value of what
we capture not being correct or correct in the context of capturing but
incorrect in the context of analysis/usage/transferring.
What can we do about this?
– a few basic principles to our rescue
1. Always store
the time in UTC from the application. You can capture in any local TZ but
please convert and store it in UTC.
2. If you
are using a DB function to capture time, use the appropriate date/time function
that provides time in UTC UTC irrespective of what the DB and the host OS TZ is
3. Have your
presentation layer translate the time in UTC
to the appropriate time for the user to view. if possible, provide an
option for the user to choose the TZ in the profile section
4. Use ISO
8601 standard
5. Don’t
write your own Date/Time parsing libraries. Use standardly available ones
6. For
existing applications, add the offset to UTC. This will help in later
normalisation
Well, Things are not so
simple. What if you want to calculate duration, say in seconds as your
application is sensitive to seconds? You would normally find the difference
between two dates. But alas! There is a something called Leap Seconds. It's an
extra second added either on June 30th or December 31st based
on the difference between the earth's rotation and the atomic clock. Sometimes,
due to the earth slowing down, there is a difference and hence a second has to
be added, and it has happened 27 times from 1972 to date.
Most of us wouldn’t need to
worry about leap seconds, but good to be aware of it
To summarise, knowledge is
power and awareness is the first step to change. Don't despair. Keep things
simple and in UTC and you shall have enough time on hand to pursue your
interests
(This was originally published in Lowe's India internal blog)
Comments