Should I (still) use UTC for all my servers?

Question

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?

Answer 1

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}

Answer 2

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:

---

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

Answer 3

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.

Answer 4

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.