There shouldn't be any need to disable it. It only fails when the date range crosses a DST transition. And now we know why.
-Adrian --- On Sat, 3/13/10, Jacopo Cappellato <[email protected]> wrote: > From: Jacopo Cappellato <[email protected]> > Subject: Re: production-run-tests.testProductionRunDateChange > To: [email protected] > Date: Saturday, March 13, 2010, 3:19 AM > 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. > > > > > > > > > >
