yum upgrades for production use, this is the repository for you.
Active subscription is required.
Setting a timezone of a CentOS/RHEL system is trivial, yet an important task.
It’s easiest to do it wrong, because most of the blogs will only give you shell commands to change the timezone, without giving any rationale on what your timezone should really be.
When you’re thinking:
I should set the timezone of my server to my own timezone
You make a mistake at the very beginning of setting up your server.
Let’s review both best practices for the timezone setting as well as how to set the timezone up on CentOS/RHEL 8.
The right timezone, for a particular case
Follow a basic rule of thumb:
- If a machine is a server, the timezone, in most cases, should be UTC.
- If the machine is only for personal use, the timezone may match up with the timezone of where the primary user is located.
Setting the timezone of your CentOS/RHEL server
Why servers should run in the UTC timezone is simple to understand.
Servers are commonly connected/used by a lot of users dispersed geographically.
“I’m running a web store, and I’m the sole user of admin, so I should set the timezone the same as my own”
Wrong.
At some point in time, you will hire a support guy from another country. Next thing, you will have the server maintained by an engineer from the other country.
It is important to note that most of the web frameworks have the expectation of the server timezone to be UTC.
Including popular frameworks like Magento.
When you set your Magento server timezone to be other than UTC, you make it prone to numerous issues including incorrect dates stored in the database.
Follow the simple rules. They apply to both Magento, and virtually any web app:
- Magento server timezone must be UTC
- Magento timezone setting (set in admin) must be the desired one.
Only following the above rules, you will not run into any issues related to the timezones, while running Magento.
UTC stands for Universal Coordinated Time, and it’s best to be used for internet-connected servers.
So do the right thing once and for all:
timedatectl set-timezone UTC
With this approach, it is still desired to define some crons to run on a timezone where most of the users are located.
For example, you have a backup cron that is I/O intensive, and you want to have it run at midnight in relation to the users of a particular country.
This can be easily accomplished by leveraging CRON_TZ environment variable. E.g. run crontab -e and have the following cron task definition:
CRON_TZ="Europe/Paris"
* * * * * /some/other/script
@daily /path/to/backup/script.sh
The CRON_TZ ensures that all cron definitions specified after it will run in a particular timezone. So the backup script will be run in the timezone of Paris, and users from this location will not be affected by the possible performance issue.
Setting the timezone of your CentOS/RHEL 8 workstation
When a machine has one primary user and does not expose any services to the outside, it is both safe and convenient to set it to your personal timezone.
Example:
timedatectl set-timezone America/Los_Angeles
Time synchronization
A frequent mistake is setting up NTP software without actual need. What is a rule of thumb here?
- Running a dedicated server? Yes, you need NTP software
- Running a VPS server? No, you probably should not install NTP software, because the host machine likely has one already
Install NTP software on CentOS/RHEL/Rocky Linux/etc
Simply run a few commands to set up NTP on your server:
sudo yum -y install chrony
To enable time synchronization, ensure the corresponding service is enabled:
sudo systemctl enable --now chronyd
A mere equivalent for the same is to run:
sudo timedatectl set-ntp true
This also enables the chronyd service, because it integrates with SystemD.
