[Bug 1372923] New: Package modified in Fedora exhibits bad behavior when / etc/localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

Bug ID: 1372923
           Summary: Package modified in Fedora exhibits bad behavior when
                    /etc/localtime is old
           Product: Fedora
           Version: 23
         Component: perl-DateTime-TimeZone
          Assignee: [e-mail]
          Reporter: [e-mail]
        QA Contact: [e-mail]
                CC: [e-mail], [e-mail],
                    [e-mail]

Description of problem:
I was on FC20 at some point, and upgraded to FC23.  I hadn't noticed until now
that my /etc/localtime was a copy and not a symlink of the Los_Angeles zoneinfo
file.  So this means my /etc/localtime file is from FC20, even though I'm on
FC23.  This causes problems with DateTime::TimeZone package.  I have this test
perl program:

#!/usr/bin/perl
use DateTime::TimeZone;
print "DateTime::TimeZone::VERSION=" . $DateTime::TimeZone::VERSION . "\n";
my $ltz = DateTime::TimeZone->new(name => 'local');
print "\n$ltz\n";
print "tz offset=" . $ltz->offset_as_string(-25200) . "\n";

On my system, this program generates the following output:

[root@pp10 ~]# perl test.pl
DateTime::TimeZone::VERSION=2.01

DateTime::TimeZone::Tzfile=HASH(0x1222668)
Can't locate object method "offset_as_string" via package
"DateTime::TimeZone::Tzfile" at test.pl line 26.
[root@pp10 ~]#

Note that DateTime::TimeZone->new(name => 'local') returned a
DateTime::TimeZone::Tzfile object.  I contacted the maintainer of
DateTime::TimeZone, and he assured me this is impossible.  He said this package
was modified, and it turns out he's right.  The package from CPAN gives the
expected result (proper error message) with the FC20 localtime file.  With a
FC23 localtime file, it also works fine (I get Los_Angeles object with offset
-0700 reported by the program).  I don't know why this package is modified
under the Fedora project.  I debugged, and found the problem to be in the
/usr/share/perl5/vendor_perl/DateTime/TimeZone/Local/Unix.pm file.  Unix.pm has
code not found in the CPAN version, so it is from the Fedora project.

Version-Release number of selected component (if applicable):
perl-DateTime-TimeZone-2.01-1.fc23.noarch

How reproducible:

Steps to Reproduce:
1. Copy /etc/localtime from an FC20 system to an FC23 system.
2. Run the above test perl program.

Actual results:
DateTime::TimeZone::Tzfile=HASH(0x1222668)
Can't locate object method "offset_as_string" via package
"DateTime::TimeZone::Tzfile" at test.pl line 26.

Expected results:
Cannot determine local time zone

Additional info:
The package from CPAN gives the expected result (proper error message) with the
FC20 localtime file.  With a FC23 localtime file, it also works fine (I get
Los_Angeles object with offset -0700 reported by the program).

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

Paul Howarth  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Paul Howarth  ---
Discussion regarding the downstream patch in Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=1135981
https://rt.cpan.org/Public/Bug/Display.html?id=55029

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

Petr Pisar  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |[e-mail]
           Assignee|[e-mail]         |[e-mail]

--- Comment #2 from Petr Pisar  ---
Fedora package was modified to use /etc/localtime via
DateTime::TimeZone::Tzfile because of bug #1135981.

The issue with DateTime::TimeZone from CPAN is it horribly dies (the "Cannot
determine local time zone" error) if time zone name is unknown but
/etc/localtime exists which is a valid configuration of a Linux system.

With Fedora's patch, instead of dying, it works in most of the cases. It only
cannot retrieve time zone name ("Can't locate object method "offset_as_string""
error) because system time zone files do not provide it.

From this point of view the Fedora's package is less broken than the CPAN's
version.

I can look if I can add the offset_as_string() method to
DateTime::TimeZone::Tzfile object in this case.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

--- Comment #3 from Don Beusee  ---
I've read some of the history on this issue, and I don't agree with maintaining
your own branch of the package.  Your fix ignores the ill configured system
(/etc/localtime out of sync with /usr/share/zoneinfo), which means the system
will give incorrect time due to rule changes which /etc/localtime doesn't know
about because it's out of date.  I'd rather SOME program tells me something is
wrong so I can fix it.  On top of localtime being wrong, tzfile's guess can
also be wrong and then you have 2 wrongs.  It's better to raise an error so the
sysadmin can fix the system and 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.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

--- Comment #4 from Petr Pisar  ---
(In reply to Don Beusee from comment #3)
> Your fix ignores the ill configured system (/etc/localtime out of sync
> with /usr/share/zoneinfo),

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 which
> /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 it.

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 and
> then you have 2 wrongs.

I don't know what you mean by "tzfile's guess". DateTime::TimeZone::Tzfile does
not guess. It simply does not provide time zone name.
> It's better to raise an error so the sysadmin can fix the system and
> everything is set right again.

Yes.
> 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.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

--- Comment #5 from Don Beusee  ---
Anytime /etc/localtime is out of date, that represents a broken system from the
sysadmin point of view, because s/he applied patches that are not properly
applied (despite being installed, it's not being used).  Any package installer
updating the zoneinfo files must deal with this problem.  However, that is not
the scope of this bug.

As a professional sysadmin and system programmer for 36 years, I submit that
patching this Perl package is wrong from both perspectives (sysadmin and
programmer).  You cannot unilaterally decide how this package will work,
because you're not the owner of it.  The owner has to deal with any/all
consequences of his/her decisions on how the package works, because s/he gets
the bug reports and support tickets.  You do the sysadmin a disservice by
patching a package that is different from the original, behaving differently
than if installed from cpan.

You have done me (a fedora user/sysadmin) a disservice because I had to spend
many hours debugging an issue that originates with an outdated localtime file
compounded by a vendor patch to a package not owned by the vendor.  When the
owner told me my error was impossible and must be locally patched, I was in
such disbelief that I spent time debugging to see exactly where the issue was,
to prove if it was patched or not.  Had I been using the original package from
the owner, I would have received a more meaningful error and much sooner got my
system fixed of the old localtime file and been on my way.

Just like the owner of glibc can decide to use /etc/localtime, the Perl package
owner can decide to use a platform neutral method of maintaining tz data.  It
is not for you or I to say it's wrong.  It is wrong however, to modify someone
else's code, especially when in disagreement with the owner.  I would not want
some vendor modifying my code and I'm sure if you were a package owner, you
wouldn't either.

You have agreed with me that it's better to raise an error so the sysadmin is
notified there is a problem, but still you disagree with raising an error? 
Well, we can disagree, but it's not really your call.  It's the owner's call.

Frankly, I'd lose trust in fedora and redhat if they continue to modify code
that's not theirs.  You should be working with package owners to resolve issues
and refer users to them when issues arise.  When I find a bug, that's what I
do, just as in this case.  I only bugged here because you modified the code in
question, and I believe that is, or at the very least, should be, outside your
purview.

Providing rpm packages in your distribution should be only a convenience so
that we don't have to install a lot of cpan packages.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

Emmanuel Seyman  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #6 from Emmanuel Seyman  ---
(In reply to Don Beusee from comment #5)
> Frankly, I'd lose trust in fedora and redhat if they continue to modify code
> that's not theirs.  You should be working with package owners to resolve

This sounds like a huge disservice to saddle our users with.

If we did not patch the software we package, bugzilla would ask Fedora users
to install perl packages via install-module.pl instead of using dnf/yum,
DBD::Sqlite would be using the bundled version of sqlite, different from what
the
rest of the distribution is using, resulting in subtle, hard-to-debug bugs. I'm
sure there are many other examples.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

--- Comment #7 from Don Beusee  ---
Bugzilla DOES tell you to install modules using install-module.pl!  LOL!  But
if you've ever run check_setup.pl, you'd know that.  Seriously, people use cpan
instead of yum/dnf all the time. This is not supposed to be a bad thing! 
Sometimes it's the only way to get the latest version people need.  Now I see
this is the only way you know what you're getting.

If redhat doesn't want to "saddle it's users", it can work with package owners
on their behalf.

Redhat should be contributing to base packages rather than maintaining its own
branches.

This is one case where the redhat code is the one "hard-to-debug".

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

--- Comment #8 from Emmanuel Seyman  ---
(In reply to Don Beusee from comment #7)
> Bugzilla DOES tell you to install modules using install-module.pl!  LOL!

Not the one we package. Per user request, we've patched bugzilla to prompt
the user to use dnf instead of install-module.pl.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

--- Comment #9 from Don Beusee  ---
I figured.  Well, you make it hard for the package owners to support their own
s/w on redhat/fedora.  I still say branching the DT::TZ pkg is unnecessary and
problematic.  Their code is perfectly fine, and I prefer it.  It would have
saved me a lot of time.  BTW, bugzilla is using it incorrectly, which I think
you know, since you're monitoring that bugzilla mailing list I emailed.  Since
it is your DT::TZ change that breaks bugzilla in this case, you might want to
fix your bugzilla.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

--- Comment #10 from Fedora End Of Life  ---
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

Petr Pisar  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|23                          |24

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

--- Comment #11 from Fedora End Of Life  ---
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

Don Beusee  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|24                          |26

--- Comment #12 from Don Beusee  ---
Petr, how do you plan to deal with the error I originally reported?  I set the
version from 24 to 26 so that this isn't auto-closed.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

Petr Pisar  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |CLOSED
         Resolution|---                         |WONTFIX
        Last Closed|                            |2017-07-26 03:46:30

--- Comment #13 from Petr Pisar  ---
I plan to keep the behavior you don't like. It's normal Fedora bends upstream
code to its needs and this is one of the cases.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

--- Comment #14 from Don Beusee  ---
So you prefer this:
DateTime::TimeZone::Tzfile=HASH(0x1222668)
Can't locate object method "offset_as_string" via package
"DateTime::TimeZone::Tzfile" at test.pl line 26.

Instead of:
Cannot determine local time zone

Even though it's a simple matter to define the routine in Tzfile to return the
friendlier error?  Ok then!

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

--- Comment #15 from Petr Pisar  ---
Like "Cannot determine local time zone name"? I could probably. But I thought
you are against any divergence from upstream code.

[Bug 1372923] Package modified in Fedora exhibits bad behavior when /etc/ localtime is old

https://bugzilla.redhat.com/show_bug.cgi?id=1372923

--- Comment #16 from Don Beusee  ---
True, but since you're diverging anyway, I'd like to see the error message
fixed.