There can be a lot of confusion writing dates and times in
01/05/12 could mean January 5, 2012
May 1, 2012. ISO 8601 attempts to
this confusion by describing an internationally accepted way to
dates and times using numbers.
ISO 8601 specifies 6 different levels of granularity with each level having enough information to identify correct date and/or time as well as the granularity it specifies. The table below shows all the levels:
|Year and Month||YYYY-MM||2016-11|
|Complete Date + Hours and Minutes||YYYY-MM-DDThh:mmTZD||2016-11-03T19:20+05:00|
|Complete Date + Hours, Minutes and Seconds||YYYY-MM-DDThh:mm:ssTZD||2016-11-03T19:20:35+05:00|
|Complete Date + Hours, Minutes, Seconds and Fraction of a Second||YYYY-MM-DDThh:mm:ss.sTZD||2016-11-03T19:20:35.45+05:00|
Note that, T forms part of the date+time string to properly separate the time part from date string.
There are two ways of handling timezones:
- Times are expressed in UTC with a special UTC designator
Z. For example,
- Times are expressed in local timezones with offset specified in
string in the format
+hh:mm. For example,
2016-11-03T19:20:35.45+05:00(Your local time is ahead of UTC) or
2016-11-03T19:20:35.45-03:00(Your local time is 3 hours behind from UTC)
Your server, regardless of which continent it is in, should always be in UTC. There are a few reasons for that:
- UTC does not have DST. If you are using any other timezone, it’s highly likely it will have DST and once a year all your cron jobs will get out of sync. And not to mention, DST is also different in different timezones
- Most organizations use UTC as their standard time so when you hire a new system admin, it’s more likely that they’ll assume your servers are in UTC as opposed to any other timezone. So, it’s easier to standardize
When you have multiple servers in multiple continents, all your systems must use the same timezone. Using a standard timezone also helps here as you don’t have to keep track of the timezone of each of the server.
Your database and server should also be in the same timezone. In
a managed database service will be in UTC. So having your server in
different timezone can cause synchronization issues. Make sure that
NOW() in the database and getting current time in your
application (on your server) should always result in the same time.
Before you start setting up a server, be sure to check if the
using UTC. You can find out your current timezone by running
which gives you something like this
Wed Mar 22 12:22:26 PKT
PKT is the timezone.
To set it to UTC, simply run the following command:
sudo timedatectl set-timezone Etc/UTC
You can verify if your settings have been updated by running
again which should give something like this now:
Wed Mar 22
Have fun staying in sync!