Inspect Time Zone Rules and DST Changes with zdump

zdump tells you what time a named zone is using right now, and exactly when its offset last changed or next will. It also exposes the interval data the local time-zone library relies on, which is worth a look when you are chasing a DST bug. The examples were run on Ubuntu 24.04 with zdump from glibc 2.39, package version libc6 2.39-0ubuntu8.9. The installed manpage comes from manpages 6.7-2.

Allow about ten minutes. You need a shell and a time-zone name such as Europe/London. Every command in this guide is read-only and runs as an ordinary user. Nothing here needs sudo, and zdump does not change the system clock or time-zone configuration.

1. Check the command and the zone name

Confirm the installed implementation before relying on examples from another operating system:

$ zdump --version
zdump (Ubuntu GLIBC 2.39-0ubuntu8.9) 2.39
$ zdump --help
zdump: usage: zdump OPTIONS TIMEZONE ...

The implementation accepts one or more time-zone names after its options. These are names from the zoneinfo database, not display labels such as BST or UTC+1. Start with an IANA name:

$ zdump Europe/London America/New_York
Europe/London     Mon Sep 28 15:29:06 2026 BST
America/New_York  Mon Sep 28 10:29:06 2026 EDT

Your timestamp will differ. The useful check is the zone name followed by the current local date, time and abbreviation. If a zone name is rejected, check its spelling against the files installed below /usr/share/zoneinfo rather than guessing a new abbreviation.

2. Limit verbose output to a useful year range

Use -v when you need the two sides of each detected time discontinuity. Without a cutoff, the command can print a very large historical and future range: the manpage documents a default of years -500 through before 2500. Add -c with a lower year and an exclusive upper year:

$ zdump -c 2024,2025 -v Europe/London
Europe/London  Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0
Europe/London  Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600
Europe/London  Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600
Europe/London  Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0

This selects transitions on or after the start of 2024 and before the start of 2025. The four lines show the last second before and the first second after each 2024 change:

• isdst=1 marks daylight-saving time.
• isdst=0 marks standard time.
• gmtoff is the local offset in seconds east of Greenwich.

The cutoff is about the interval you inspect, not a change to the zone database. Always add a narrow -c when output will be logged, compared or pasted into a ticket.

3. Choose between -v and -V

Verbose mode includes extreme representable timestamps and boundary information as well as transitions. That is useful when checking the complete behaviour of the local time functions, but it adds noise. Use -V for the same transition-focused report without the extreme time and year values:

$ zdump -V -c 2024,2025 Europe/London
Europe/London  Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0
Europe/London  Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600
Europe/London  Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600

Do not treat this as a promise that every implementation prints byte-for-byte identical text. zdump is reporting the time representation available to the local C library. -V is the better choice when comparing systems with different time representations, but compare the zone, timestamps, offset and daylight-saving marker rather than assuming identical surrounding lines.

4. Produce compact interval data

Use -i when a compact, tab-separated description is easier to process or review:

$ zdump -i -c 2024,2025 Europe/London

TZ="Europe/London"
-  -  +00  GMT
2024-03-31  02  +01  BST  1
2024-10-27  01  +00  GMT

The real output begins with an empty line and uses tabs between fields. It identifies the zone, gives the interval before the first transition, then lists each transition and the interval that follows it. Times are local time immediately after the transition. In an interval such as +01 BST 1, the offset is one hour east of Greenwich, BST is the abbreviation, and 1 marks daylight-saving time.

The example's first historical line is included because -i describes the zone interval that precedes the selected transition range. If you need a report containing only a small modern window, use -c and read the initial interval line as context, not as a 2024 transition.

5. Use time cutoffs when years are not precise enough

For a boundary expressed as seconds since the Unix epoch, use -t instead of -c:

$ zdump -V -t 1704067200,1735689600 Europe/London

The lower timestamp is inclusive and the upper timestamp is exclusive. Both values are decimal seconds since 1970-01-01 00:00:00 UTC. The time zone affects whether leap seconds are included in that count, so do not mix a timestamp produced for one zone's leap-second interpretation with an assumption from another tool. For ordinary civil-time checks, year cutoffs are easier to read and explain.

Common traps

• Overclaiming what the report proves. A transition report describes the rules known to this machine's time-zone data and the behaviour of its glibc time functions. It does not prove that a remote host, container or application uses the same database or library. Run the bounded command on each relevant host and record the glibc version, zone name and cutoff.
• Misreading UT as always modern UTC. The manpage says UT denotes the result from gmtime. Modern timestamps use UTC, while some older timestamps use another UT flavour: it is not a guarantee that every historical line should be read as modern UTC terminology.
• Trusting a clean report on an artificial zone. Discontinuities are found by sampling localtime at twelve-hour intervals. That works for real-world zones, but a deliberately unusual custom zone can defeat that method. Treat a clean report as evidence about the sampled data, not as formal proof that no discontinuity exists.