production-run-tests.testProductionRunDateChange

[Adam Heath-2]

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?

[Adrian Crum-2]

--- On Fri, 3/12/10, Adam Heath <[hidden email]> 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.

[Adam Heath-2]

Adrian Crum wrote:

> --- On Fri, 3/12/10, Adam Heath <[hidden email]> 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

[Adrian Crum-2]

--- On Fri, 3/12/10, Adam Heath <[hidden email]> wrote:

> Adrian Crum wrote:
> > --- On Fri, 3/12/10, Adam Heath <[hidden email]>
> 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.

[Adam Heath-2]

Adrian Crum wrote:

> --- On Fri, 3/12/10, Adam Heath <[hidden email]> wrote:
>> Adrian Crum wrote:
>>> --- On Fri, 3/12/10, Adam Heath <[hidden email]>
>> 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.

>
>
>
>      

[Adrian Crum-2]

--- On Fri, 3/12/10, Adam Heath <[hidden email]> wrote:

> Adrian Crum wrote:
> > --- On Fri, 3/12/10, Adam Heath <[hidden email]>
> wrote:
> >> Adrian Crum wrote:
> >>> --- On Fri, 3/12/10, Adam Heath <[hidden email]>
> >> 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

[Adam Heath-2]

Adam Heath wrote:

> Adrian Crum wrote:
>> --- On Fri, 3/12/10, Adam Heath <[hidden email]> wrote:
>>> Adrian Crum wrote:
>>>> --- On Fri, 3/12/10, Adam Heath <[hidden email]>
>>> 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.

[Adam Heath-2]

Adrian Crum wrote:

> --- On Fri, 3/12/10, Adam Heath <[hidden email]> wrote:
>> Adrian Crum wrote:
>>> --- On Fri, 3/12/10, Adam Heath <[hidden email]>
>> wrote:
>>>> Adrian Crum wrote:
>>>>> --- On Fri, 3/12/10, Adam Heath <[hidden email]>
>>>> 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.

[Adrian Crum-2]

--- On Fri, 3/12/10, Adam Heath <[hidden email]> wrote:

> Adam Heath wrote:
> > Adrian Crum wrote:
> >> --- On Fri, 3/12/10, Adam Heath <[hidden email]>
> wrote:
> >>> Adrian Crum wrote:
> >>>> --- On Fri, 3/12/10, Adam Heath <[hidden email]>
> >>> 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.

[Jacopo Cappellato-4]

On Mar 13, 2010, at 6:48 AM, Adrian Crum wrote:

>
> 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.
>

Adrian,

I would like a suggestion for fixing the test.

Here are some assumptions and details of the test:
1) the availability/capacity (calendar) of the fixed asset is the same every week: 8hours per day from 8am to 4pm from Monday to Friday
2) the goal of the test is to verify if the same exact task (i.e. a constant amount of time of usage for the fixed asset) when is started "tomorrow" (e.g. Friday this week) takes the same time to complete of when it is started the same day of the next week (e.g. Friday of the next week)
3) in order to determine the two dates (tomorrow and the same day next week), since I didn't want to hardcode the date, I used the trick of adding 1 day to "now" (this is the first date) and adding 8 days to "now" (this is the second date)
4) the above two dates are used as starting dates for the tasks and the ending dates are determined; the test asks that the differences between the ending date and starting date of first period and the ending date and starting date of the same period is the same

Is this error caused when the DST is happening inside one of the time ranges computed in #4? This is what I understand...
Any suggestion for fixing this (apart from hardcoding the dates)?

Thanks!

Jacopo

[Jacopo Cappellato-4]

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 <[hidden email]> wrote:
>> Adam Heath wrote:
>>> Adrian Crum wrote:
>>>> --- On Fri, 3/12/10, Adam Heath <[hidden email]>
>> wrote:
>>>>> Adrian Crum wrote:
>>>>>> --- On Fri, 3/12/10, Adam Heath <[hidden email]>
>>>>> 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.
>
>
>
>

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: Jacopo Cappellato <[hidden email]>
> Subject: Re: production-run-tests.testProductionRunDateChange
> To: [hidden email]
> 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 <[hidden email]>
> wrote:
> >> Adam Heath wrote:
> >>> Adrian Crum wrote:
> >>>> --- On Fri, 3/12/10, Adam Heath <[hidden email]>
> >> wrote:
> >>>>> Adrian Crum wrote:
> >>>>>> --- On Fri, 3/12/10, Adam Heath
> <[hidden email]>
> >>>>> 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.
> >
> >
> >
> >
>
>

[Adrian Crum-2]

--- On Sat, 3/13/10, Jacopo Cappellato <[hidden email]> wrote:

> On Mar 13, 2010, at 6:48 AM, Adrian Crum wrote:
>
> >
> > 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.
> >
> 4) the above two dates are used as starting dates for the
> tasks and the ending dates are determined; the test asks
> that the differences between the ending date and starting
> date of first period and the ending date and starting date
> of the same period is the same
>
> Is this error caused when the DST is happening inside one
> of the time ranges computed in #4? This is what I
> understand...

That is correct.

Wall Clock Time = WCT
Elapsed Time = ET

2010-03-01 20:30 WCT plus 8 days WCT = 2010-03-09 20:30 WCT = 192 hours ET
2010-03-12 20:30 WCT plus 8 days WCT = 2010-03-20 20:30 WCT = 191 hours ET

2010-03-01 20:30 WCT plus 192 hours ET = 2010-03-09 20:30 WCT
2010-03-12 20:30 WCT plus 192 hours ET = 2010-03-20 19:30 WCT

-Adrian



     

[Jacopo Cappellato-4]

Thanks,

I have fixed it (and re enabled) in rev. 922813
I have used the "trick" to compare for equality but also accept a difference of +1 or -1

It should be ok for this test.

Jacopo

On Mar 13, 2010, at 5:39 PM, Adrian Crum wrote:

> --- On Sat, 3/13/10, Jacopo Cappellato <[hidden email]> wrote:
>> On Mar 13, 2010, at 6:48 AM, Adrian Crum wrote:
>>
>>>
>>> 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.
>>>
>> 4) the above two dates are used as starting dates for the
>> tasks and the ending dates are determined; the test asks
>> that the differences between the ending date and starting
>> date of first period and the ending date and starting date
>> of the same period is the same
>>
>> Is this error caused when the DST is happening inside one
>> of the time ranges computed in #4? This is what I
>> understand...
>
> That is correct.
>
> Wall Clock Time = WCT
> Elapsed Time = ET
>
> 2010-03-01 20:30 WCT plus 8 days WCT = 2010-03-09 20:30 WCT = 192 hours ET
> 2010-03-12 20:30 WCT plus 8 days WCT = 2010-03-20 20:30 WCT = 191 hours ET
>
> 2010-03-01 20:30 WCT plus 192 hours ET = 2010-03-09 20:30 WCT
> 2010-03-12 20:30 WCT plus 192 hours ET = 2010-03-20 19:30 WCT
>
> -Adrian
>
>
>
>