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.
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 EDTYour 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.
Checkpoint: Run the plain command for the zone you are investigating. If its output is sufficient, stop there. The following steps are for rules, transitions and machine-readable comparisons.
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=0This 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:
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.
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=3600Do 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.
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 GMTThe 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.
For a boundary expressed as seconds since the Unix epoch, use -t instead of -c:
$ zdump -V -t 1704067200,1735689600 Europe/LondonThe 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.
Tip: Keep the bounds explicit in scripts. A bare -v is easy to leave running with an unexpectedly large output stream, especially when its output is redirected to a file or consumed by a logging service.
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.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.-c or -t before saving or comparing it.