Bug 1460042
| Summary: | perl-DateTime gets incorrect offset , time and abbreviation in some cases due to not being current. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Mark <mark.a.sloan> |
| Component: | perl-DateTime | Assignee: | perl-maint-list |
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.9 | CC: | ppisar, psabata |
| Target Milestone: | rc | Keywords: | Rebase |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-06-09 05:21:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. getting correct time is a "feature" not a bug huh ? 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. (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. |
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.