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: >>>> 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. > > 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
Actually, you're right. nowTimestamp + nextStartWorkDay nowTimestamp + 8 days + nextStartWorkDay nextStartWorkDay is pseudo-code; on Friday, it means Monday. And, of course, since this is doing date calculations based on the current date, in timezones that have DST, it fails 4 times a year; once, when the first range straddles the DST, and a second time when second range straddles it, times two for the spring and fall. So, yes, this is purely a bug in just this test case.
