[Bug libc/1140] zdump reports invalid timezone name

["egmont at uhulinux dot hu" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From egmont at uhulinux dot hu  2005-09-28 14:51 -------
Dear Ulrich,

Please let me prove you wrong.

First of all, I'd like to mention _again_ that I already reported this problem
to the address you just gave me now.

Second, I'd like to mention _again_ that the original tzcode package behaves
correctly if compiled by simply typing "make", outside the glibc source tree.

Third, even if glibc uses zdump.c unmodified, it uses a completely own
Makefile to build zdump and hence it is being built with completely different
flags. Therefore your argument of using zdump unmodified is not fully correct.
It really doesn't matter if zdump.c is the same or not as long as it is
compiled in a completely different way.

Actually, now that I looked at the problem once again, tzcode ships a
localtime.c that provides an own localtime() implementations as well as some
other functions. In tzcode's Makefile there's a line
TZDOBJS=        zdump.o localtime.o ialloc.o
which instructs to link zdump against the own version of localtime.o, hence
this zdump doesn't use glibc's localtime() and maybe some similar functions,
and this zdump behaves correctly.

If I remove localtime.o from this line then the resulting zdump will behave
incorrectly.

I don't know the reason why zdump uses an own localtime implementation. Maybe
to workaround a bug in some libc's, including glibc. Maybe to workaround a bug
in zdump itself. I really don't know.

I don't even know if the real cause of the bug resides in tzcode or in glibc.

I only know that the original tzcode behaves correctly if compiled with the
Makefile the authors created, however, in glibc these building rules are
ignored and the new ones lead to an incorrect binary.

Believe me, I'd happly see this bugreport closed as wontfix if you convince me
that this is really not a glibc bug. But at this moment I don't think so. The
authors of zdump say "compile it this way, it'll be okay", and it will really
be okay. Glibc says "we don't compile it this way, we compile it that way" and
then it becomes buggy. Is it really a tzcode/zdump bug then???


Ps. Ulrich, I'd be extremely happy if you took the time to _carefully_ read
bug reports. It's not my first report where your comment clearly indicates that
you bypass important details in the report. Or are my English or bugreporting
skills really so awful? Please tell me if I'm wrong but it seems to me that I
clearly stated in my original report that the mainstream zdump behaves
correctly, and I also clearly stated that I reported the bug to the tzcode
maintainers too. It seems that you forgot about both of these two details when
commenting on my report.

Ps2. I really don't want to waste your time, so if you happen to want to answer
something like "you're wrong, go away" or "if you reopen this bug again I'll
have to revoke your bugzilla account" or a similar answer, don't bother, just
close it again as wontfix, I'll understand what you mean and I'll disappear,
at least from this bugreport. On the other hand, I'd very much like to hear a
different answer, if possible. Not necessarily from you, but from anyone of the
glibc team. From someone who managed to understand what this bug is about.
Thanks in advance. :)


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |


http://sourceware.org/bugzilla/show_bug.cgi?id=1140

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.