"John" <mjensen@theriver.com> a écrit dans le message de
news:mjensen-897D4A.10353708032005@msnews.microsoft.com...
>
> > Hi John,
> > Did you tried the formula on a task with "standard" duration (vs.
elapsed
> > duration) with or without any splits?
> >
> > Gérard
>
> Gerard,
> If you reply please start a new thread. I normally have my newsreader
> set for 100 messages and this one dropped "below my radar". I had to
> remember to check.
>
> The file I used contains "standard" working day duration and no split
> tasks. It is just your generic type file, nothing special or unusual. If
> the Duration field is already in "edays" there isn't any need for the
> formula, right? As far as split tasks, the elapsed duration is still the
> difference between Start and Finish. The split simply becomes part of
> that time.
>
> By the way I use a standard calendar (U.S. holidays) with 8 hour days
> and 40 hour work week. It just doesn't make sense to put an additional
> "fudge factor" into the formula without a good reason. So far, I haven't
> seen that reason.
>
> John

John,

I tried again on Project 2000 (with a 40h/w calendar) and on Project 2003
(with a french 35h/w calendar) : the result is the same: all the
calculations on standard durations are short by one day. On elapsed
durations (with "ed"), the result is good.
??? ;-(

Gérard

Re: Determining Calendar Days in MS Porject 2000 by John

John
Tue Mar 08 21:53:45 CST 2005


> John,
>
> I tried again on Project 2000 (with a 40h/w calendar) and on Project 2003
> (with a french 35h/w calendar) : the result is the same: all the
> calculations on standard durations are short by one day. On elapsed
> durations (with "ed"), the result is good.
> ??? ;-(
>
> Gérard

Gerard,
Somethings fishy somewhere. Does the need for a fudge factor make sense
to you? It doesn't to me. Therefore we need to find out why. There is a
reason for everything. Try this experiment. Set up two tasks with the
same Start and Finish dates. On one task set the Duration as working
days. On the other task, enter the Duration as "edays". Now use your
formula in a spare duration field for both tasks. What do you get (I get
an extra day for both tasks)?

Here's another experiment. Use a spare text field instead of a spare
duration field. That way there is no need to compensate for the
formatting which is automatically applied to the duration fields. Does
the formula still require a fudge factor?

Finally, use VBA instead of a formula to populate a spare text field. Is
the fudge factor needed to give the correct answer?

By the way, I forgot to mention that my file uses a standard start time
of 8:00 am and a finish time of 5:00 pm with a 1 hour lunch break.

John

Re: Determining Calendar Days in MS Porject 2000 by Gérard

Gérard
Thu Mar 10 01:39:15 CST 2005

John

<<Does the need for a fudge factor make sense to you?>>
No, of course !

I tried every experiment you suggested, on both French and English version,
with always the same result.
Could you send me the .mpp file sample you used ?
My address is: ducouret dot gerard at free dot fr

Thanks,

Gérard Ducouret



Re: Determining Calendar Days in MS Porject 2000 by John

John
Thu Mar 10 11:28:09 CST 2005

In article <uUXyDRUJFHA.732@TK2MSFTNGP12.phx.gbl>,
"Gérard Ducouret" <gerard.ducouret@wanadooNOSPAM.fr> wrote:

> John
>
> <<Does the need for a fudge factor make sense to you?>>
> No, of course !
>
> I tried every experiment you suggested, on both French and English version,
> with always the same result.
> Could you send me the .mpp file sample you used ?
> My address is: ducouret dot gerard at free dot fr
>
> Thanks,
>
> Gérard Ducouret

Gerard,
Good, I'm glad it doesn't make sense to you either.

You betcha. As soon as I'm done checking the newsgroup and taking care
of a few other things, I"ll send you my file. However, my bet is there
is something unique about the way you have Project configured and my
file will most likely give the same result as you get with your file(s).

I'm a little surprised none of the other MVPs checked in on our
discussion. Certainly they must have experience or at least an opinion
of what may be going on.

John
Project MVP

Re: Determining Calendar Days in MS Porject 2000 by JulieS

JulieS
Fri Mar 11 16:09:10 CST 2005

Hi John and Gérard,

I'm not an MVP, but can I play too?

I agree with Gérard's results.
When I enter John's original formula in a spare Duration field, I too end up
one day short except for tasks that are elapsed duration.

I am using Project 2003 Professional, SP-1. US English. Hours per day = 8,
No modifications to Standard calendar.

If you gentlemen find the answer, please post it. Thanks.

Julie

"John" wrote:
> Gerard,
> Good, I'm glad it doesn't make sense to you either.
>
> You betcha. As soon as I'm done checking the newsgroup and taking care
> of a few other things, I"ll send you my file. However, my bet is there
> is something unique about the way you have Project configured and my
> file will most likely give the same result as you get with your file(s).
>
> I'm a little surprised none of the other MVPs checked in on our
> discussion. Certainly they must have experience or at least an opinion
> of what may be going on.
>
> John
> Project MVP
>

Re: Determining Calendar Days in MS Porject 2000 by Steve

Steve
Sat Mar 12 05:42:39 CST 2005

This may be one of those slap the forehead moments but I'm wondering if
everyone is counting the days between two dates the same way? In the whole
thread, no one has mentioned any concrete examples <grin>.

Days between dates - do we start counting at day 1 or day zero? If the
first date is Monday 12noon and the second date is Friday at 12 noon, should
the formula show 5 days or 4? When I count it on my fingers, I get 4 days:
M->T is day 1, T->W is day 2, W->T is day 3, T->F is day 4. The formula
subtracting Mon 12N from Fri 12N should result in 4 days. Are those finding
it "1 day short" getting 3 when expecting 4 or are they getting 4 when
expecting 5?


--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs




"JulieS" <JulieS@discussions.microsoft.com> wrote in message
news:852D8C37-3EE2-49A7-8B90-A2FD01BFA500@microsoft.com...
> Hi John and Gérard,
>
> I'm not an MVP, but can I play too?
>
> I agree with Gérard's results.
> When I enter John's original formula in a spare Duration field, I too end
> up
> one day short except for tasks that are elapsed duration.
>
> I am using Project 2003 Professional, SP-1. US English. Hours per day =
> 8,
> No modifications to Standard calendar.
>
> If you gentlemen find the answer, please post it. Thanks.
>
> Julie
>
> "John" wrote:
>> Gerard,
>> Good, I'm glad it doesn't make sense to you either.
>>
>> You betcha. As soon as I'm done checking the newsgroup and taking care
>> of a few other things, I"ll send you my file. However, my bet is there
>> is something unique about the way you have Project configured and my
>> file will most likely give the same result as you get with your file(s).
>>
>> I'm a little surprised none of the other MVPs checked in on our
>> discussion. Certainly they must have experience or at least an opinion
>> of what may be going on.
>>
>> John
>> Project MVP
>>


Re: Determining Calendar Days in MS Porject 2000 by Gérard

Gérard
Sat Mar 12 05:44:05 CST 2005

Hi Julie,

Thanks for your feedback !

Gérard

"JulieS" <JulieS@discussions.microsoft.com> a écrit dans le message de
news:852D8C37-3EE2-49A7-8B90-A2FD01BFA500@microsoft.com...
> Hi John and Gérard,
>
> I'm not an MVP, but can I play too?
>
> I agree with Gérard's results.
> When I enter John's original formula in a spare Duration field, I too end
up
> one day short except for tasks that are elapsed duration.
>
> I am using Project 2003 Professional, SP-1. US English. Hours per day =
8,
> No modifications to Standard calendar.
>
> If you gentlemen find the answer, please post it. Thanks.
>
> Julie
>
> "John" wrote:
> > Gerard,
> > Good, I'm glad it doesn't make sense to you either.
> >
> > You betcha. As soon as I'm done checking the newsgroup and taking care
> > of a few other things, I"ll send you my file. However, my bet is there
> > is something unique about the way you have Project configured and my
> > file will most likely give the same result as you get with your file(s).
> >
> > I'm a little surprised none of the other MVPs checked in on our
> > discussion. Certainly they must have experience or at least an opinion
> > of what may be going on.
> >
> > John
> > Project MVP
> >



Re: Determining Calendar Days in MS Porject 2000 by Gérard

Gérard
Sat Mar 12 06:41:50 CST 2005

Hello Steve,
Any concrete example :
A task is beginning on Monday at 8:00, it's finishing on Friday at 17:00
with a standard calendar (8 hours per day)
The Project Duration field announces 5 days and many people count the same
way.
The incriminated formula:
DateDiff("d";[Start];[Finish])*[Minutes per day]
...announces 4 days.

Gérard Ducouret


"Steve House [MVP]" <sjhouse.remove.this@to.send.hotmail.com> a écrit dans
le message de news:OwObYivJFHA.3788@tk2msftngp13.phx.gbl...
> This may be one of those slap the forehead moments but I'm wondering if
> everyone is counting the days between two dates the same way? In the whole
> thread, no one has mentioned any concrete examples <grin>.
>
> Days between dates - do we start counting at day 1 or day zero? If the
> first date is Monday 12noon and the second date is Friday at 12 noon,
should
> the formula show 5 days or 4? When I count it on my fingers, I get 4
days:
> M->T is day 1, T->W is day 2, W->T is day 3, T->F is day 4. The formula
> subtracting Mon 12N from Fri 12N should result in 4 days. Are those
finding
> it "1 day short" getting 3 when expecting 4 or are they getting 4 when
> expecting 5?
>
>
> --
> Steve House [MVP]
> MS Project Trainer & Consultant
> Visit http://www.mvps.org/project/faqs.htm for the FAQs
>
>
>
>
> "JulieS" <JulieS@discussions.microsoft.com> wrote in message
> news:852D8C37-3EE2-49A7-8B90-A2FD01BFA500@microsoft.com...
> > Hi John and Gérard,
> >
> > I'm not an MVP, but can I play too?
> >
> > I agree with Gérard's results.
> > When I enter John's original formula in a spare Duration field, I too
end
> > up
> > one day short except for tasks that are elapsed duration.
> >
> > I am using Project 2003 Professional, SP-1. US English. Hours per day =
> > 8,
> > No modifications to Standard calendar.
> >
> > If you gentlemen find the answer, please post it. Thanks.
> >
> > Julie
> >
> > "John" wrote:
> >> Gerard,
> >> Good, I'm glad it doesn't make sense to you either.
> >>
> >> You betcha. As soon as I'm done checking the newsgroup and taking care
> >> of a few other things, I"ll send you my file. However, my bet is there
> >> is something unique about the way you have Project configured and my
> >> file will most likely give the same result as you get with your
file(s).
> >>
> >> I'm a little surprised none of the other MVPs checked in on our
> >> discussion. Certainly they must have experience or at least an opinion
> >> of what may be going on.
> >>
> >> John
> >> Project MVP
> >>
>



Re: Determining Calendar Days in MS Porject 2000 by John

John
Sat Mar 12 11:56:09 CST 2005


Steve,
Gerard and I exchanged e-mails off line on this issue. I figured it out
(at least for my understanding) and will post a separate message for the
benefit of all.

John

Re: Determining Calendar Days in MS Porject 2000 by John

John
Sat Mar 12 11:58:41 CST 2005

In article <852D8C37-3EE2-49A7-8B90-A2FD01BFA500@microsoft.com>,
JulieS <JulieS@discussions.microsoft.com> wrote:

> Hi John and Gérard,
>
> I'm not an MVP, but can I play too?
>
> I agree with Gérard's results.
> When I enter John's original formula in a spare Duration field, I too end up
> one day short except for tasks that are elapsed duration.
>
> I am using Project 2003 Professional, SP-1. US English. Hours per day = 8,
> No modifications to Standard calendar.
>
> If you gentlemen find the answer, please post it. Thanks.
>
> Julie

Julie,
Sure you can "play". There is nothing that give us a lock on anything
just because we are allowed to add MVP to our title.

Since the original question is of general interest, I am posting a new
message explaining what I found.

John