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