Red Hat Bugzilla – Bug 174984
missing timezone variable for Asia/Yekaterinburg in /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm
Last modified: 2007-11-30 17:11:18 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: Programs using Date::Manip doesn't work if timezone is set to Asia/Ekaterinburg(YEKT),cause of missing timezone variable in /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm Version-Release number of selected component (if applicable): perl-DateManip-5.42a-4 How reproducible: Always Steps to Reproduce: 1. sudo logwatch Actual Results: ERROR: Date::Manip unable to determine TimeZone. at /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm line 3495 Date::Manip::Date_TimeZone called at /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm line 661 Date::Manip::Date_Init() called at /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm line 779 Date::Manip::ParseDateString('epoch 1133701851') called at /usr/share/logwatch/lib/Logwatch.pm line 508 Logwatch::TimeBuild() called at /usr/sbin/logwatch line 663 Expected Results: working logwatch Additional info: Here is patch to solve it: --- /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm 2003-07-02 22:42:47.000000000 +0600 +++ Manip.pm 2005-12-05 17:57:34.000000000 +0500 @@ -606,6 +606,7 @@ "zp4 +0400 ". # USSR Zone 3 "msd +0400 ". # Moscow Daylight "zp5 +0500 ". # USSR Zone 4 + "yekt +0500 ". # Asia/Yekaterinburg "ist +0530 ". # Indian Standard "zp6 +0600 ". # USSR Zone 5 "novst +0600 ". # Novosibirsk time zone, Russia
Yes, there are MANY missing, duplicate or non-existent zones in DateManip's zonesrfc variable. The DateManip code must be extensively revised in order to deal with duplicate zone abbreviations such as CST, which could mean GMT offsets of -0600, -0500, 0800, 0930, or 1030 depending on which timezone / location is selected. I've raised an upstream DateManip bug report on this issue: http://rt.cpan.org/NoAuth/Bug.html?id=16360 which will hopefully be fixed soon in the next upstream DateManip release. If not, we'll have to extensively rewrite parts of DateManip to deal with the duplicate timezone issue - an upstream fix would be better . Meanwhile, you've found the correct temporary solution with your patch . We'll have a more comprehensive solution for this issue soon.
*** This bug has been marked as a duplicate of 100786 ***