--- Comment #4 from Petr Pisar <ppisar(a)redhat.com> ---
(In reply to Don Beusee from comment #3)
Your fix ignores the ill configured system (/etc/localtime out of
This is not ill-configured system. First, glibc reads /etc/locatime, not
/usr/share/zoneinfo. Second, DateTime::TimeZone does not use
/usr/share/zoneinfo at all. It carries it's own time zone database and that's
much bigger problem.
which means the system will give incorrect time due to rule changes
/etc/localtime doesn't know about because it's out of date.
No. System always respects what's in /etc/locatime. It's actually
DateTime::TimeZone that ignores it.
I'd rather SOME program tells me something is wrong so I can fix
From POSIX point of view, there is nothing wrong with the system. From Fedora
point of view, you have a local configuration that overrides system time zone
definition and such configuration is not a subject of updates.
If something should tell you it's suboptimal, it's not DateTime::TimeZone.
Probably a package manager.
I've decided for the patch because it allows systems that exist in the wild to
work. Such systems are even used in Fedora build infrastructure. (That's how I
hit this issue.)
On top of localtime being wrong, tzfile's guess can also be wrong
then you have 2 wrongs.
I don't know what you mean by "tzfile's guess".
not guess. It simply does not provide time zone name.
It's better to raise an error so the sysadmin can fix the system
everything is set right again.
And you don't have to maintain a branch of
code trying to ignore a DST patch not properly applied. I am betting you
could talk the package owner into producing a better error message
indicating something being wrong with /etc/localtime.
I don't know what DST patch you talk about. Do you mean tzdata package update?
Then you can raise your idea in tzdata bug #107507.
You are receiving this mail because:
You are on the CC list for the bug.