--- On Fri, 3/12/10, Adam Heath <[email protected]> wrote: > Adam Heath wrote: > > Adrian Crum wrote: > >> --- On Fri, 3/12/10, Adam Heath <[email protected]> > wrote: > >>> Adrian Crum wrote: > >>>> --- On Fri, 3/12/10, Adam Heath <[email protected]> > >>> wrote: > >>>>> ah ha! > >>>>> > >>>>> This is just excellent. > >>>>> > >>>>> Has anyone tried running the test > suite right > >>> now? In > >>>>> the US? > >>>>> > >>>>> The above test fails, because the > start date is > >>> now, but > >>>>> the end date > >>>>> is in the future *past* when daylight > savings time > >>> takes > >>>>> place. So > >>>>> the interval is off by one hour, and > the assertion > >>> fails. > >>>>> Does anyone have any ideas about a > fix? > >>>> Does the test code use millisecond > arithmetic? If yes, > >>> then the test fails. Use the TimeDuration > class instead, or > >>> the localized Timestamp adjustment methods in > UtilDateTime. > >>>> Give me a file name and line number. In > return I will > >>> give you more information. > >>> > >>> ant run-single-test-suite > -Dtest.component=manufacturing > >>> -Dtest.suiteName=productionruntests > >>> > >>> line 260 in > >>> > applications/manufacturing/script/org/ofbiz/manufacturing/test/ProductionRunTests.xml > >> There is a flaw in the test code logic. You can't > schedule the start and end of a production run in some point > in the past, and then compare that to the start and end time > of some point in the future and then expect them to come out > the same. > >> > >> In other words, the demo data is based on a > certain elapsed time in the past. The test creates a new > production run based on the same elapsed time, but in the > future. So, the timestamps are going to come out different. > > > > Not completely. > > > > The test case worked for ages. Last Friday, it > started failing for > > me. But, then it started working for me again on > Saturday, so I > > didn't think anything of it. > > > > Then, tonight, it broken again. > > > > This coincides with it jumping the start time by 8 > days. It also > > tells me that the test is fine, and it's the > underlying helper code > > that is broken. > > > > Maybe something in quickChangeProductionRunStatus is > not doing > > interval management correctly. > > TechDataServices.addForward and > TechDataServices.capacityRemaining > looks bad, esp. the ZONE_OFFSET and DST_OFFSET in the > latter.
Understanding the difference between wall clock time and elapsed time is especially important in manufacturing. They are completely different, and manufacturing depends on both. The problem with the test is it advances the wall clock, then compares elapsed time. They are not the same - the test is comparing apples to oranges.
