My employer is located in Europe (CET), and therefore we use daylight saving time, which requires shifting an hour hence and forth twice a year. Our servers are running in the cloud in different locations. The employee who set up all the infrastructure is gone. He decided to use UTC as the system time zone on all servers (currently Ubuntu 18.04, 20.04, and 22.04).

This is not ideal, because you have to mentally add 1/2 hours to every date you see in a log file, depending on the time of the year (+2 hours in the summer, +1 hour in the winter). The timing of some cronjobs also needs to be adjusted twice a year, because the tasks should be run at noon CET.

Is there any good reason to (still) use UTC as the system's time zone? Or should I rather switch to CET, so that my cronjobs and logfiles better align to the wall clock?

  • 1
    personally, I would switch the the timezone that is most suitable to your requirements - of course, a user ... nevermind comment below mentioned what I was going to say Commented Apr 5, 2023 at 6:53
  • 9
    Sounds like "personal preference" to me. Do it whatever way makes sense to you. Also you can use multiple timezones / per process, by setting TZ (or CRON_TZ). Though that may be even more confusing than a single timezone for everything... Commented Apr 5, 2023 at 6:53
  • 2
    +1 to CRON_TZ. Our servers are contractually mandated to be UTC, but they "live" in the US east coast. Thus, it's set to America/New_York, as is TZ in .bash_profile.
    – RonJohn
    Commented Apr 5, 2023 at 8:03
  • 2
    I would: (1) set up one of your servers as time server that is queried by the others (time and timezone changes will only have to applied once); (2) read the logs via a perl wrapper that corrects timezone issues (adds or subtract hours); (3) store current time difference to UTC in a file on every server. All servers should live in a homogenous UTC environment; CET is for being easier read by humans.
    – syck
    Commented Apr 5, 2023 at 15:53
  • 3
    what do you mean "still"? Is there some reason to assume there would have been more reason for that before, but not now??
    – ilkkachu
    Commented Apr 5, 2023 at 17:00

4 Answers 4


Is there any good reason to (still) use UTC as the system's time zone?

Yes absolutely! Consider a major event that happens on 29 October 2023 at 02:30. Log messages are duly generated. (The relevance of this date/time is that the clocks across Europe go back by one hour that morning, and for the CEST/CET switch it's at 3am that morning.)

If you're running UTC the timestamps are unambiguous*. You might need to convert to CEST/CET but you know for certain the absolute time. On the other hand if you're running in local time you first need to try and work out if this was the first or second time through the period from 02:00 to 03:00. Depending on the quantity of log messages this may not be possible.

Cron jobs used to be a problem but either using CRON_TZ or migrating to systemd timer units as suggested in another answer will address that neatly.

* apart from the occasional leap second, that is, as mentioned by akostadinov

  • 1
    What's CRON_TZ? What cron implementations support it? Commented Apr 5, 2023 at 8:39
  • 1
  • 3
    @ilkkachu That's EU harmonization for you: all the EU countries in the EET/CET/WET timezones begin and end summer time at the same points in UTC time regardless of timezone, to minimize the hassles in scheduling between neighboring countries on the transition nights.
    – telcoM
    Commented Apr 5, 2023 at 19:16
  • 3
    If you use the systemd journal for logging (which does have a lot of other advantages over plain text files), timestamps are always internally stored as UTC and only optionally converted to local when displaying the log. No need to work out anything in your head.
    – TooTea
    Commented Apr 6, 2023 at 8:06
  • 2
    "UTC the timestamps are unambiguous", if only those leap seconds did not exist... but I agree, much better than DTS leaps. Commented Apr 7, 2023 at 16:46

I can really understand your log-reading pain, but I wouldn't want to discuss times in log files with my American and German colleagues during the ca 2 weeks a year where Daylights saving time has affected one continent, but not the other¹. Personally, while that certainly isn't as relevant for services that have mostly local usage (e.g. a print server – not like someone in Arizona will print on my Southern German printer), I've found anything but UTC timestamps in mail server logs vastly confusing.

Regarding your cron jobs: I'm slowly trying to wean myself off good ole crontab, in favor of systemd timer units. They have an OnCalendar= field, and that takes a timezone specification! So, you can still say, hey, awesome, at 7:00 AM in Berlin, kick of that RFC 2324 transfer, or whatever.

All in all, yeah, for a server, stay in UTC. But, in all honesty, I think consistency is more important than "Müller's perceived administrative beauty" here. If the rest of your admin scope / adjacent teams and users expect CET, then by all means: Go CET. Things should work.

For levity:

Mastodon post: ** HEADS UP US-based sysadmins ** Before going to bed tonight, be sure to leave the UTC clocks on your servers as they are.

¹ I might be an outlier. My mechanical wristwatch is in UTC as well.

  • 5
    Good point: one time zone requires one mental adjustment; multiple time zones multiple mental adjustments. Systemd timer units can solve the issue I'm having with cronjobs. Commented Apr 5, 2023 at 7:10
  • 2
    "MPAB" sounds cooler than UTC", though! :) Commented Apr 5, 2023 at 18:11
  • 1
    @JaminGrey You may need to look up names rather than use the city name literally, but that should be an option. Using e.g. "UTC-5" is a bad idea because you'll need to change it any time daylight savings changes. Commented Apr 6, 2023 at 6:22
  • 3
    @JaminGrey yours appears to be America/Chicago. See time.is/Kansas_City and search for IANA Commented Apr 6, 2023 at 7:57
  • 2
    @JaminGrey: It's not as bad. Your place switches twice a year between UTC-5 and UTC-6 whereas it stays in America/Chicago all year long. In essence, America/Chicago encodes the DST rules of your location. Commented Apr 7, 2023 at 8:37

Servers should always store UTC. Local time is a presentation layer issue that only humans need to see. If you, as a user, want to look at some timestamped data, then you probably want to see it in your time zone, which is irrespective of what the server thinks it is.

UTC is unambiguous for everyone (including leap days/seconds) and will never overlap with any daylight savings time (except for exceptional circumstances).

Local times can (and do) overlap every 6 months, so if you were looking at logs that have used local time as a timestamp, March would appear to be missing that hour, and October would have that hour twice.

  • 7
    UTC may be unambiguous wrt. leap seconds, but POSIX time isn't, as it essentially ignores leap seconds. Hence the Google thing of handling them by counting the same number of seconds but veery slightly adjusting their length.
    – ilkkachu
    Commented Apr 5, 2023 at 17:06
  • 1
    "Local time is a presentation layer issue that only humans need to see." the reality is that unix largely works on configuration and log files consisting of human readable/writable text, there is no "presentation layer".
    – plugwash
    Commented Apr 5, 2023 at 17:11
  • 7
    I'd be a bit more nuanced: Servers should always store time in the form it was originally generated, and where possible those timestamps should be generated in UTC. However if you don't control the generation, you should not convert the data prior to storing it. There is too much risk that you will get things wrong in the conversion (time zone information changes), if you need to, store the original value and your current converted value, but you should never discard the original per-convertion value. Commented Apr 5, 2023 at 21:18
  • 2
    @Neil That's a problem for UK developers, where half the year bugs confusing UTC and local time have no effect. I once had a bug that broke things between midnight UTC and midnight local time on the first day of the month. Australian customers complained because it was broken if they arrived at work early.
    – gnasher729
    Commented Apr 6, 2023 at 13:06
  • 2
    @Neil GMT does not "go back" or "go forward". It is practically equivalent to UTC. UK summer time is not GMT, it's BST.
    – user3730
    Commented Apr 6, 2023 at 13:22

You see the disadvantages of UTC (hard to translate into local time mentally). You don't see the advantages of UTC or rather the lack of problems: Having every server agree on the time is very, very valuable. You'd find out very quickly if you changed your servers to some local time.

Keep your servers on UTC. You might consider creating some tools that help you examining the logs. Such a tool might for example display dates in local time. Or group logs closely together in time. Or replace 32 byte unreadable ids with "id1", "id2", etc. so you know what log lines belong to the same action. Or remove 1000 almost identical log lines.

  • 1
    "hard to translate into local time mentally" - timezone adjustments come with practice. I'm in the UK so although UTC is rarely a problem for me to convert, I have offices around the world and it does take a little effort to adjust by -8 hours (US/Canada west), +2 hours (Ukraine), or even +12/14 hours (AU/NZ) Commented Apr 7, 2023 at 18:55
  • India is easiest to convert, just turn your watch 180 degrees :-) (India Standard Time is 4:30 hours forward from GMT, so this trick only works there).
    – Neil
    Commented Apr 26, 2023 at 19:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .