Latest response

I have read articles describing that UTC is technically a time "standard" whereas GMT is a time "zone".

As far as timekeeping on the server these are both valid configurations. Is there any functional difference on how they keep time? Is there any reason to go with one over the other?


UTC is the time standard used for many Internet and World Wide Web standards and Most modern unix (and Linux) use UTC. NTP also uses UTC for time synchronisation.

UTC is based on TAI (International Atomic Time) and has fixed length seconds. Because the planet doesn't keep accurate time, "leap" seconds are used to adjust the base time to keep it in track with earth time. GMT can be considered equivalent to UTC, when the leap seconds don't matter. However, it is most appropriate to use and refer to time based on UTC and not on GMT.

So our recommendations is to always use UTC on your systems. solution found in

So when UTC is used does the system automatically adjust for leap seconds?

The kernel handles leap seconds and keeps track of seconds since epoch. Timezone offsets are solely a userspace concept.

By using the zdump -v <timezone> command, you can verify that there is no technical difference in the definitions of "UTC" and "GMT" time zones.

But I would still say that UTC is preferred because it unambiguously documents that you're using world-wide Coordinated Universal Time which won't ever observe Daylight Saving Time.

If a timezone is specified with just "GMT", it might mean the same as "UTC"... or it might mean that between the end of March and the end of October, there will be a Daylight Saving Time switch to BST (British Summer Time) which is UTC +1 hour.

Leap second adjustment is not tied to timezones, unless you make the effort of setting your system clock to TAI instead of UTC. That would be necessary only if you have a specific requirement to use TAI (International Atomic Time) as your time base: for most regular uses, UTC is more convenient.

To automatically adjust for leap seconds, you need something that will inform the kernel in advance that a leap second will happen at the end of the current UTC day. ntpd can do that, but only if certain conditions apply:

  • if you download an up-to-date list of leap seconds from or one of its mirrors and specify its pathname with the leapfile keyword in your ntp.conffile, then ntpd will know about past and currently-decided future leap seconds, and will inform the kernel as appropriate.

  • or if you sync your time from a NTP server that already has the leap second information, it can pass on the information on upcoming leap seconds to its clients. That NTP server might have a leap file configured, or might be using a reference clock that can provide the leap second warning information (e.g. some GPS clock receivers can do it, but not all of them).

If you use the leap second file, you can verify that it works by running this command:

$ ntpq -c "rv 0 leap,tai,leapsec,expire"
leap=00, tai=37, leapsec=201701010000, expire=201806280000

That means:

  • leap=00: no leap second expected today; if a leap second will happen at the end of the current UTC day, this will indicate "leap=01" instead.

  • tai=37: the current offset between TAI and UTC. Whenever a leap second happens, this number will be incremented by one.

  • leapsec=201701010000: the last leap second occurred just before 2017-01-01 00:00:00 UTC

  • expire=201806280000: the current leap second file says that there definitely will be no new leap second until 2018-06-28 at least.

The leap second file is updated at half-year intervals: a new file will be published in January 2018 and will determine whether there will be a leap second after 2018-06-30 23:59:59 UTC or not.