Interesting. These are all tests that use things like week of year/month, and we have had issues in the past with unexpected results using some of those patterns (e.g. DAFFODIL-488), so I'm not entirely surprised that these these tests fail. But it is odd that our results aren't consistent, they all pass for the current devs and they pass on TravisCI. I'd guess that ICU (the library we use for date/time parsing) is getting some value from your system that we aren't correctly overriding. I believe we've had that problem in the past, but thought it was all fixed.
I've tried changing my timezone and tests still pass. Have you made any other date time related configurations to your system? Maybe you've changed the calendar type or have a non-standard first day of week, days in first week, language, etc? This also might just be a weird bug in ICU. The version we currently use is pretty old. You might try changing the ICU dependency in project/Dependencies.scala to the latest (61.1) and see if that fixes it. I've tested that and get a bunch of errors related to rounding and various number errors, but all the calendar tests pass. We may want to move these tests to scala-debug until we can resolve this issue. - Steve On 05/24/2018 04:47 AM, Russ Williams wrote: > Hi! > > Testing the build process with a clone of the current master branch, I’m > getting five test failures related to calendar handling for day-of-week and > week-of-year. > > One in daffodil-test-ibm1/test: > [error] Test > org.apache.daffodil.IBMTestsThatPass.test_simple_type_properties_text_calendar_13_01 > failed: java.lang.Exception: > [error] Comparison failed. > [error] Expected > [error] > <myDateTime>2010-12-27T04:05:06.000000+00:00</myDateTime> > [error] Actual > [error] > <myDateTime>2010-12-20T04:05:06.000000+00:00</myDateTime> > > > Four in daffodil-test/test: > [error] Test > org.apache.daffodil.section05.simple_types.TestSimpleTypes.test_dateCalendarDaysInFirstWeek3 > failed: java.lang.Exception: > [error] Comparison failed. > [error] Expected > [error] <date17>2012-01-01+00:00</date17> > [error] Actual > [error] <date17>2012-12-23+00:00</date17> > > [error] Test > org.apache.daffodil.section05.simple_types.TestSimpleTypes.test_dateCalendarDaysInFirstWeek5 > failed: java.lang.Exception: > [error] Comparison failed. > [error] Expected > [error] <date20>2013-02-24+00:00</date20> > [error] Actual > [error] <date20>2013-02-10+00:00</date20> > > [error] Test > org.apache.daffodil.section05.simple_types.TestSimpleTypes.test_dateCalendarFirstDayOfWeek03 > failed: java.lang.Exception: > [error] Comparison failed. > [error] Expected > [error] <date06>2013-02-03+00:00</date06> > [error] Actual > [error] <date06>2013-02-02+00:00</date06> > > [error] Test > org.apache.daffodil.section05.simple_types.TestSimpleTypes.test_dateCalendarFirstDayOfWeek04 > failed: java.lang.Exception: > [error] Comparison failed. > [error] Expected > [error] <date06>2013-02-04+00:00</date06> > [error] Actual > [error] <date06>2013-02-03+00:00</date06> > > > The dateCalendarDaysInFirstWeek3 failure is particularly bad since it’s > looking for “week 1 of 2012”, which should start on 2012-01-01, but it’s > getting a date in *December* 2012. > > > Every other test passes cleanly. > I’ve got the same result on my Mac (macOS Sierra/10.12.6, Oracle Java > 1.8.0_51-b16) and a Linux box (Ubuntu 16.04 LTS, Oracle Java 1.8.0_111-b14). > Setting -Duser.timezone in JAVA_OPTS doesn’t make any difference. > I haven’t been able to test with OpenJDK yet. > > Cheers, > — > Russ >
