Bug 1176177
Summary: | .spec file %check fails : TestTwoDigitYear | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Jason Vas Dias <jason.vas.dias> |
Component: | icu | Assignee: | Eike Rathke <erack> |
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.7 | CC: | tpelka |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | icu-4.2.1-11.el6 | Doc Type: | Bug Fix |
Doc Text: |
Cause: 2-digit year roll-over of century in test case. Note that input of 2-digit year 34 now results in 2034 instead of 1934.
Consequence: A check during build time failed.
Fix: Compare the test result to next century.
Result: The test case passes.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2015-03-10 10:05:30 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: |
Description
Jason Vas Dias
2014-12-19 15:54:53 UTC
I think the date parser is mistakenly trying to parse the date given default british 'MM/DD/YY', but you've supplied the US style "DD/MM/YY" : 915 SimpleDateFormat fmt("dd/MM/yy", Locale::getUK(), ec); You should be using Locale::getUS(), because I have set : export LANG=en_US.UTF-8 export LC_ALL=en_US.UTF-8 which is the setting in /etc/sysconfig/i18n AND in the environment of the process. Apparently, the .spec file is not honoring settings from either /etc/sysconfig/i18n or from the environment, but ONLY from the host's location and is insisting that dates without centuries have the UK MM/dd/yy format, even though you've specified dd/MM . I have even tried : $ rm /etc/localtime $ ln -s /usr/share/zoneinfo/EST /etc/localtime and reconfiguring & rebuilding from scratch, but with same result. Perhaps it is using DNS / NTP / GeoIP / keyboard to determine location ? I use a UK keyboard layout - maybe that is it ? Even with LANG and LC_ALL set in the environment as 'en_US.UTF-8', AND /etc/localtime being a link to /usr/share/zoneinfo/EDT , AND with LANG=en_US.UTF-8 in /etc/sysconfig/i18n , the test still is loading the Locale::getUK() locale . $ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=en_US.UTF-8 $ LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw ./intltest ... -------------------------------------- Errors in total: 1. TestTwoDigitYear DateFormatTest format -------------------------------------- Elapsed Time: 00:00:59.000 Same as bug 1106793 That darn two-digit year is now EOL.. Apply a patch similar to http://pkgs.fedoraproject.org/cgit/icu.git/commit/icu-testtwodigityear.patch?h=f21&id=3320ff38f29cb6dff40f62452ce8fc653fc89786 With this patch applied to 4.2.1-9.1 : <code> diff -up source/test/intltest/dtfmttst.cpp.bz1176177 source/test/intltest/dtfmttst.cpp --- source/test/intltest/dtfmttst.cpp.bz1176177 2009-07-01 19:50:24.000000000 +0100 +++ source/test/intltest/dtfmttst.cpp 2015-01-05 10:42:32.744004326 +0000 @@ -918,7 +918,7 @@ DateFormatTest::TestTwoDigitYear() return; } parse2DigitYear(fmt, "5/6/17", date(117, UCAL_JUNE, 5)); - parse2DigitYear(fmt, "4/6/34", date(34, UCAL_JUNE, 4)); + parse2DigitYear(fmt, "4/6/34", date(134, UCAL_JUNE, 4)); } // ------------------------------------- </code> all test cases pass. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0664.html |