(A backward compatibility note: if tzloadbody is changed to treat non-slash arguments as filenames that aren't relative to the default time zone directory, it should probably be set up to also look in the default directory to avoid breaking anything that counts on the current behavior.) @dashdashado On Sun, Oct 28, 2018 at 7:21 PM Arthur David Olson < arthurdavidolson@gmail.com> wrote:

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

Robert Elz wrote:

zdump could be taught that if its zone arg is obviously intended to be a filename, rather than a zone name (like it starts ./ or ../) then it should simply prepend ${PWD}/ to the start of it, so it gets a fully qualified name, which works.

zdump was designed to be independent of the underlying implementation. It doesn't know about file names. All it does is set the TZ environment variable and go. There is value in keeping zdump simple like this, as it provides a way to test any string that you could set TZ to. We could add an option to zdump which would mean "prepend $PWD to arguments not beginning with slash", or something like that; but I suspect it's hardly worth the trouble, as anybody who would know about the option would also know about $PWD and can just prepend it themselves.

On 2018-10-28 21:20, Paul Eggert wrote:

Matt Johnson wrote:

...

zdump ./New_York The output is missing the abbreviation: ./New_York  Sun Oct 28 22:23:48 2018 That's an old zdump, or one built with some non-default build-time flags. The current zdump (2018g), if built in the default way, behaves like this: $ zdump ./New_York || echo failed $? ./New_York: No such file or directory failed 1 which at least lets you know that zdump isn't doing what you thought it would do.

Linux distros using glibc package zdump, zic, tzselect in a binary helper package called libc-bin on Debian/Ubuntu, glibc-common on RH distros, and other base (or sometimes optional) packages on other Linux and non-Linux distros. Distro releases of zdump, zic may be updated with tzdata releases, or when the distro maintainer decides tzcode updates need applied, and that may be selective. Run zdump --version to get some idea of the zdump release (often just libc ver). -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.