Bug 1460042 - perl-DateTime gets incorrect offset , time and abbreviation in some cases due to not being current.
perl-DateTime gets incorrect offset , time and abbreviation in some cases due...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: perl-DateTime (Show other bugs)
6.9
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: perl-maint-list
BaseOS QE - Apps
: Rebase
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-08 18:21 EDT by Mark
Modified: 2017-06-12 07:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-09 01:21:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark 2017-06-08 18:21:46 EDT
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:
everytime. 

rpm is perl-DateTime-0.5300-3



Steps to Reproduce:
1. create test for locales that changed since ~ 2012???
2. e.g. 
use strict;
use DateTime;


my $time = DateTime->new(
    year   => 2016,
    month  => 12,
    day    => 22,
    hour   => 22,
    minute => 30,
    second => 0,
    time_zone => 'Europe/Istanbul',
);

print "The date and time in Europe/Istanbul : ", $time->strftime('%Y-%m-%d %T %z %Z');
print "\n"




3. run script. 

Actual results:
The date and time in Europe/Istanbul : 2016-12-22 22:30:00 +0200 EET

Expected results:
The date and time in Europe/Istanbul : 2016-12-22 22:30:00 +0300 +03

(as this is what DateTime 1.43 from CPAN gets)

Additional info:


Please note this is just ONE locale that is incorrect with respect to offset and in this case the abbreviation is also now wrong for perl-DateTime's version. as the official TZData update for 2016g noted 


"     Turkey switched from EET/EEST (+02/+03) to permanent +03,
     effective 2016-09-07.  (Thanks to Burak AYDIN.)  Use "+03" rather
     than an invented abbreviation for the new time. " 


I'm sure there are some other cases where additional locales can be identified that are now getting the incorrect time, possibly abbreviation as well. 


I see that several other BZs have been closed with won't fix when people have asked for updates to perl-DateTime, which confuses me as updates to this package allow people to get the correct time (or at least more correct).

my request is that perl-DateTime be current and reflect more accurate timestamp with timezone calculations.
Comment 2 Petr Pisar 2017-06-09 01:21:06 EDT
Red Hat Enterprise Linux 6 reached Production 3 Phase <https://access.redhat.com/support/policy/updates/errata/#Production_3_Phase> when no new features are provided. Therefore this bug report will be closed.

If this bug is urgent for you, please contact Red Hat Support <https://access.redhat.com/support> to reevaluate your issue properly.

Another option is to migrate to Red Hat Enterprise Linux 7.
Comment 3 Mark 2017-06-09 11:23:29 EDT
getting correct time is a "feature" not a bug huh ?
Comment 4 Mark 2017-06-09 11:27:36 EDT
if the tzdata package is being updated still on RHEL 6 why isn't perl-DateTime. they both allow systems to get corrected timezone calculation updates such that time is accurate. 

i'm raising this via support. 

it's just as incorrect in RHEL7.
Comment 5 Petr Pisar 2017-06-12 07:13:18 EDT
(In reply to Mark from comment #3)
> getting correct time is a "feature" not a bug huh ?

Getting time according to _new_ time zone definition is a feature.

(In reply to Mark from comment #4)
> if the tzdata package is being updated still on RHEL 6 why isn't
> perl-DateTime.

Because it's not deemed important enough from point of view of RHEL update machinery. That's why I recommend you to reach Red Hat Support. This is the only way how customers can emphasize their troubles.

> i'm raising this via support. 
>
Thanks.

> it's just as incorrect in RHEL7.

Yes, I know. Again, there was no customer demanding the update.

Note You need to log in before you can comment on or make changes to this bug.