If this is a bug I'd characterize it as a localtime.c bug rather than a zdump bug. Note first that zdump arguments are time zone names rather than file names. However, the localtime.c code is prepared to use a zone name as the name of a file when appropriate. If a zdump argument beginning with a slash is passed to tzalloc, it will be taken as an absolute filename. But if a name does NOT begin with a slash (for example, "./New_York") it is taken as a name within the default time zone directory. In the case at hand, there's no "New_York" file in the default directory (although there is an "America/New_York" file), so the software punts to its default; thus the differing behaviors. The "taken as a name within the default time zone directory" behavior is arguably worng (and, even if not worng, might best be documented). The relevant code is in the "tzloadbody" function. There's some complexity in that code that may not be necessary. Since time zone code gets compiled into programs run with root privileges, we want to ensure that the real user is entitled to read a file specified as the source of time zone information; that's done with an "access" call. The code tries to avoid the access call in "safe" cases--cases where the file is sure to be somewhere under zoneinfo (not specified as an absolute file name, and with no possibility of a ".." in the name). If we're willing to call access in all cases, the code for avoiding the access call can go. @dashdashado On Sun, Oct 28, 2018 at 6:31 PM Matt Johnson <mj1856@hotmail.com> wrote:
I notice when I run zdump like this:
zdump /usr/share/zoneinfo/America/New_York
The output is normal: America/New_York Sun Oct 28 18:23:35 2018 EDT
But if I change to the America directory... cd /usr/share/zoneinfo/America zdump ./New_York
The output is missing the abbreviation: ./New_York Sun Oct 28 22:23:48 2018
Is this expected? Seems like a subtle bug to me. The abbreviations are also missing with -v output.
(Ran on Ubuntu Linux 16.04.5 LTS)
Thanks, Matt