--- On Fri, 3/12/10, Adam Heath <doo...@brainfood.com> wrote: > Adrian Crum wrote: > > --- On Fri, 3/12/10, Adam Heath <doo...@brainfood.com> > wrote: > >> Adrian Crum wrote: > >>> --- On Fri, 3/12/10, Adam Heath <doo...@brainfood.com> > >> 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.
2010-03-01 20:30 plus 8 days = 2010-03-09 20:30 = n elapsed hours 2010-03-12 20:30 plus 8 days = 2010-03-20 20:30 = n - 1 elapsed hours
