I installed the attached doc patch to tzdb try to clarify things. The documented zdump behavior is kind of weird, but now's not the time to change it as we're about to do a new tzdb release.
>From d5f78a4326b94809e1cba6fcc4b59ba2a10b2d1c Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@xxxxxxxxxxx> Date: Thu, 23 Apr 2020 15:53:24 -0700 Subject: [PATCH] Clarify zdump -c * zdump.8: Clarify -c cutoff timestamps. Problem reported by Marco Curell via Michael Kerrisk; see: https://bugzilla.kernel.org/show_bug.cgi?id=207345 --- zdump.8 | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/zdump.8 b/zdump.8 index fb6b8df..98109ad 100644 --- a/zdump.8 +++ b/zdump.8 @@ -74,11 +74,11 @@ implementations with different time representations. Cut off interval output at the given year(s). Cutoff times are computed using the proleptic Gregorian calendar with year 0 and with Universal Time (UT) ignoring leap seconds. -The lower bound is exclusive and the upper is inclusive; for example, a -.I loyear -of 1970 excludes a transition occurring at 1970-01-01 00:00:00 UTC but a -.I hiyear -of 1970 includes the transition. +Cutoffs are at the start of each year, where the lower-bound +timestamp is exclusive and the upper is inclusive; for example, +.B "\*-c 1970,2070" +selects transitions after 1970-01-01 00:00:00 UTC +and on or before 2070-01-01 00:00:00 UTC. The default cutoff is .BR \*-500,2500 . .TP -- 2.17.1
