How to Check the Timezone in Linux: Quick Commands for Any Distro, Scripts, PHP, MySQL and Python

Updated: 8 October 2026 · Applies to: Debian 13, Ubuntu 26.04 (uutils date 0.10.0), AlmaLinux 10 and Alpine 3.24; PHP 8.3, MariaDB 11.8, MySQL 8.4 and Python 3.14

To check the timezone on any Linux system, run date '+%Z %z': it prints the zone abbreviation and the offset from UTC. For the full zone name, run timedatectl show -p Timezone --value on a system with systemd, or readlink -f /etc/localtime anywhere else:

$ date '+%Z %z'
IST +0530
$ timedatectl show -p Timezone --value
Asia/Kolkata
$ readlink -f /etc/localtime
/usr/share/zoneinfo/Asia/Kolkata

This article collects quick, read-only checks that also work in scripts and containers. To change the zone, see check and change the timezone on Debian and Ubuntu or the timezone on AlmaLinux, Rocky Linux, RHEL and Fedora.

1. Offset and abbreviation: date

date +%Z prints the abbreviation and date +%z the offset. Use the offset (or the full name) in scripts and logs, because abbreviations are not unique:

$ TZ=Asia/Kolkata date '+%Z %z'
IST +0530
$ TZ=Europe/Dublin date '+%Z %z'
IST +0100

2. Zone name on systemd systems: timedatectl

timedatectl show -p Timezone --value prints only the name, so it is easy to use in a variable. It needs systemd as the init system. In an AlmaLinux 10 container without it, the command failed with System has not been booted with systemd as init system (PID 1). Can't operate., and the Debian 13 and Ubuntu 26.04 container images do not include it at all (timedatectl: command not found).

3. Zone name without systemd: /etc/localtime

The system zone is the file /etc/localtime, normally a link into /usr/share/zoneinfo. readlink -f follows it to the full path: /usr/share/zoneinfo/Etc/UTC on Debian 13, /usr/share/zoneinfo/UTC on AlmaLinux 10. Two things to know:

• The Ubuntu 26.04 and Alpine container images have no /etc/localtime and no zone files, so they run on UTC and readlink prints nothing useful.
• /etc/timezone does not exist on Debian 13, Ubuntu 26.04 or AlmaLinux 10. Do not rely on it.

4. The TZ variable overrides everything

If TZ is set, programs use it instead of the system zone, while timedatectl still shows the system setting. Check it with:

$ echo "${TZ:-TZ is not set}"
TZ is not set

A wrong name is not reported. TZ=Asia/Kolkatta date '+%Z %z' printed Asia +0000 with GNU date and UTC +0000 with the uutils date on Ubuntu 26.04: both silently fell back to UTC. The same happened with a correct name on a system without the tzdata package, so check the offset after setting TZ.

5. A function for scripts

get_tz() {
  if [ -n "$TZ" ]; then echo "$TZ"; return; fi
  timedatectl show -p Timezone --value 2>/dev/null && return
  if [ -L /etc/localtime ]; then readlink -f /etc/localtime | sed 's|.*/zoneinfo/||'; return; fi
  echo "unknown name, offset $(date +%z)"
}

It printed Asia/Kolkata on AlmaLinux 10 with systemd, Etc/UTC in a Debian 13 container, unknown name, offset +0000 in the Ubuntu 26.04 and Alpine images, and Europe/London everywhere once TZ=Europe/London was set. It works in bash and in plain sh.

6. The zone of one process, service or user

A running process keeps the environment it started with. Look for TZ in it (no output means the process uses the system zone):

$ tr '\0' '\n' < /proc/2/environ | grep ^TZ=
TZ=America/New_York

For a systemd service, the variable is in the unit:

$ systemctl show -p Environment demo
Environment=TZ=Europe/London

For a user, test a login shell: su - alice -c 'date +%Z'. On Debian, an export TZ=Europe/London line at the end of alice's ~/.bashrc was ignored (it printed UTC), because the default ~/.bashrc stops at the top in non-interactive shells. After moving it to ~/.profile, the same command printed BST.

7. PHP, MySQL or MariaDB, and Python

Applications can use a different zone from the system. One line each:

$ php -r 'echo date_default_timezone_get(), PHP_EOL;'
UTC
$ mysql -e "SELECT @@system_time_zone, @@time_zone, NOW(), UTC_TIMESTAMP();"
+--------------------+-------------+---------------------+---------------------+
| @@system_time_zone | @@time_zone | NOW()               | UTC_TIMESTAMP()     |
+--------------------+-------------+---------------------+---------------------+
| IST                | SYSTEM      | 2026-10-08 12:11:12 | 2026-10-08 06:41:12 |
+--------------------+-------------+---------------------+---------------------+
$ python3 -c 'import time; print(time.tzname, time.strftime("%z"))'
('IST', 'IST') +0530

• PHP ignores the system zone and the TZ variable. PHP 8.3 printed UTC on a server set to Asia/Kolkata, because date.timezone defaults to UTC according to the PHP manual. The command line and the web server can load different php.ini files (php --ini shows the one the command line uses), so check from a web page as well. See set the default timezone in PHP.
• MySQL 8.4 and MariaDB 11.8 gave the same result (the login comes from ~/.my.cnf). According to the MySQL manual, SYSTEM means the server uses the system zone, @@system_time_zone is set when the server starts, and the server might not notice a later change of /etc/localtime until it is restarted. The difference between NOW() and UTC_TIMESTAMP() shows the offset in use.
• Python follows the system zone and TZ. datetime.now().astimezone().strftime("%Z %z") gives the same answer (IST +0530).

If the clock itself is wrong rather than the zone, see how to synchronise time with NTP.