A while ago I was fighting with a timezone set on a server because of the daylight saving time kicked in: during the ghost hour I had troubles with finding automated jobs. Moreover, the server was located overseas and depending on when I was checking the remote date and time, I could get a different time delta.
Then, the quasi-philosophical question about “which timezone should be set for a remote server: my timezone or local timezone to the server?” has began rolling in my mind.
After some research, I found a piece of technical advice from Yeller. In short, their advice can be summarized with:
(no, really check the linked post: it is full of good and agreeable technical points to use UTC).
After setting the default timezone for all my servers to UTC, there are some tweaks to live happily ever after with UTC.
First, add your timezone and export it into the
echo 'export TZ=/usr/share/zoneinfo/Europe/Rome' >> ~/.zshrc
This brings a notable advantages:
Mon Mar 25 20:56:43 2019
Mar 25 20:57:51 golf systemd-logind: Session 980 logged out. Waiting for processes to exit.
setyou get every message* localized in the selected timezone:
Mon Mar 25 21:57:53 CET 2019
Mar 25 21:57:51 golf systemd-logind: Session 980 logged out. Waiting for processes to exit.
* = every message from a sane and decently written program that knows about timezones and honors the TZ variable.
Secondly, I usually have everything running in a tmux session with the time in the tab bar. After changing the server timezone to UTC, tmux was outputting the time in UTC: I wanted to show my local time as well. In order to show localized time, you have to change some parameters:
- Output the time and the timezone in the tab bar:
set -g status-right '%a %b %d %H:%M %Z'
- Make sure to send your
TZvariable whenever you are using SSH:
- Make sure that your SSH server automatically accepts the
AcceptEnv [...] TZ