Adam, Adrian, in the meantime thanks for the bug report (on the automated test!), I have disabled it for now and I will bring it back as soon as I will fix it.
Jacopo On Mar 13, 2010, at 6:48 AM, Adrian Crum wrote: > --- 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. > > > >
