Adam Heath 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.
TechDataServices.addForward and TechDataServices.capacityRemaining looks bad, esp. the ZONE_OFFSET and DST_OFFSET in the latter.
