In zdump(8)from man-pages-5.06, row 81 (zdump -c) and row 98 (zdump -t): The lower bound is exclusive and the upper is inclusive. In my terminal (xterm) this command has an opposte behavior: [marco@casa man]$ zdump -c 2018,2020 -i Europe/Rome Europe/London TZ="Europe/Rome" - - +01 CET 2018-03-25 03 +02 CEST 1 2018-10-28 02 +01 CET 2019-03-31 03 +02 CEST 1 2019-10-27 02 +01 CET TZ="Europe/London" - - +00 GMT 2018-03-25 02 +01 BST 1 2018-10-28 01 +00 GMT 2019-03-31 02 +01 BST 1 2019-10-27 01 +00 GMT
My guess is this: in "-c 2018,2020", 2018 is translated to the seconds equivalent of '2018-01-01 00:00:00" and likewise for 2020. And though the seconds range may be treated as low-bound-exclusive plus high-bound-inclusive, the user is easily confused, because the output *looks like* low-bound-year-inclusive plus high-bound-year-inclusive. I've sent a mail with you in CC; perhaps Paul Eggert can help us.
Created attachment 288689 [details] 0001-Clarify-zdump-c.patch 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.
On Fri, 24 Apr 2020 at 00:57, Paul Eggert <eggert@cs.ucla.edu> wrote: > > 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. Thanks, Paul. If you wold be so nice as to drop me a note when the release is done, I will resync that pages in man-pages. Thanks, Michael
I've updated to the lastest zdump.8 upstream page, which now says: Cutoffs are at the start of each year, where the lower- bound timestamp is exclusive and the upper is inclusive; for example, -c 1970,2070 selects transitions after 1970-01-01 00:00:00 UTC and on or before 2070-01-01 00:00:00 UTC. Thanks to that change from Paul Eggert, I think this bug can now be closed, and I'm doing so now.