Return to Answer

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.

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}

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 03: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 4am 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.

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.

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 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.

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 03: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 4am 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.