Six months from today.
Six months from today.
This is a topic for an orphaned message.
I agree that the algorithm used needs to satisfy the business requirements, and that my rework of Barries algorithm makes an assumption relating to its behaviour on March 31, May 31, and August 29-31 which has not been stated in the rather scant documentation. Im going to make the following definitive statement though:
Solutions based on adding 180 or 182 days DO NOT solve the problem of adding 6 months. Instead they address the problem of adding 180 or 182 days. While there are potentially 5 days where the results of Barries algorithm are dubious, there are many more where adding 182 days does not get you a result that many people would expect - try it for any day in any month other than October or December and you will be up to 2 days earlier than youd expect or 1 day later.
On the issue of whether 6 months from August 31 should be taken as March 2 or February 28/29, I see the point you are making, but Im not sure. I tried turning it around and looking for the date 6 months prior to August 31, and I realised that all of our schemes fail to find such a date except the 182 day rule which would set it at March 2!
Best Regards,
Ken Wallis
Empower Data Solutions Pty Limited
Blue Mountains, Sydney, Australia
Envision, enable, enhance, ... Empower
> From: Klein Doyen T [mailto:Klein.DT@edreyfus.com]
> I suppose its a matter of opinion/application but I like my idea
> better. The month number is always 6 larger, and if it ends up
> greater than the last
> day of them month, you decrement to make sure the month never
> increases by
> 7. I say this because the original poster posed the problem
> in terms of 6
> months, not 180 days.
>
> 8/29 = 2/29 (or 2/28 in a non-leap year)
> 8/30 = same
> 8/31 = same
> 9/1 = 3/1
> -----Original Message-----
> From: Ken Wallis [mailto:kenws@empower.aust.com]
> > From: FFT2001@aol.com [mailto:FFT2001@aol.com]
>
> > run it for 9/01/99
> > and tell us what you get
>
> Barries algorithm operating against internal format dates would
> produce (in your "DMDY2" format) 3/02/00 which is of course not quite
> right.
>
> The beauty of his approach is that you add the current day of the
> month to the internal representation of the first of the month 6 from
> this one. Since every month has a first day it succeeds (so long as
> you subtract one
> to allow for the fact that there isnt a zeroeth of the month).
>
> Using this modification of Barries algorithm on (in your
> format) 8/29/99,
> 8/30/99, 8/31/99 and 9/01/99 would yield respectively 2/29/00,
> 3/01/00, 3/02/00 and 3/01/00 which is a bit weird I suppose, but I
> cant think of a
> closer approximation, can you Will?
>
> Best Regards,
>
> Ken Wallis
> Empower Data Solutions Pty Limited
> Blue Mountains, Sydney, Australia
>
> Envision, enable, enhance, ... Empower
>
> > writes:
> >
> > > Hi all. Lets see if this works:
> > >
> > > FUTURE.MONTH = @MONTH + 6
> > > FUTURE.YEAR = @YEAR
> > > IF FUTURE.MONTH > 12 THEN FUTURE.MONTH -= 12 ;
> > FUTURE.YEAR +=
> > > 1
> > > FUTURE.DATE =
> > ICONV(FUTURE.MONTH:-01-:FUTURE.YEAR,D) + @DAY
> > >
> > > Running this on 10/17/01 produces 04/18/02.
Solutions based on adding 180 or 182 days DO NOT solve the problem of adding 6 months. Instead they address the problem of adding 180 or 182 days. While there are potentially 5 days where the results of Barries algorithm are dubious, there are many more where adding 182 days does not get you a result that many people would expect - try it for any day in any month other than October or December and you will be up to 2 days earlier than youd expect or 1 day later.
On the issue of whether 6 months from August 31 should be taken as March 2 or February 28/29, I see the point you are making, but Im not sure. I tried turning it around and looking for the date 6 months prior to August 31, and I realised that all of our schemes fail to find such a date except the 182 day rule which would set it at March 2!
Best Regards,
Ken Wallis
Empower Data Solutions Pty Limited
Blue Mountains, Sydney, Australia
Envision, enable, enhance, ... Empower
> From: Klein Doyen T [mailto:Klein.DT@edreyfus.com]
> I suppose its a matter of opinion/application but I like my idea
> better. The month number is always 6 larger, and if it ends up
> greater than the last
> day of them month, you decrement to make sure the month never
> increases by
> 7. I say this because the original poster posed the problem
> in terms of 6
> months, not 180 days.
>
> 8/29 = 2/29 (or 2/28 in a non-leap year)
> 8/30 = same
> 8/31 = same
> 9/1 = 3/1
> -----Original Message-----
> From: Ken Wallis [mailto:kenws@empower.aust.com]
> > From: FFT2001@aol.com [mailto:FFT2001@aol.com]
>
> > run it for 9/01/99
> > and tell us what you get
>
> Barries algorithm operating against internal format dates would
> produce (in your "DMDY2" format) 3/02/00 which is of course not quite
> right.
>
> The beauty of his approach is that you add the current day of the
> month to the internal representation of the first of the month 6 from
> this one. Since every month has a first day it succeeds (so long as
> you subtract one
> to allow for the fact that there isnt a zeroeth of the month).
>
> Using this modification of Barries algorithm on (in your
> format) 8/29/99,
> 8/30/99, 8/31/99 and 9/01/99 would yield respectively 2/29/00,
> 3/01/00, 3/02/00 and 3/01/00 which is a bit weird I suppose, but I
> cant think of a
> closer approximation, can you Will?
>
> Best Regards,
>
> Ken Wallis
> Empower Data Solutions Pty Limited
> Blue Mountains, Sydney, Australia
>
> Envision, enable, enhance, ... Empower
>
> > writes:
> >
> > > Hi all. Lets see if this works:
> > >
> > > FUTURE.MONTH = @MONTH + 6
> > > FUTURE.YEAR = @YEAR
> > > IF FUTURE.MONTH > 12 THEN FUTURE.MONTH -= 12 ;
> > FUTURE.YEAR +=
> > > 1
> > > FUTURE.DATE =
> > ICONV(FUTURE.MONTH:-01-:FUTURE.YEAR,D) + @DAY
> > >
> > > Running this on 10/17/01 produces 04/18/02.
> From: Ken Wallis [mailto:kenws@empower.aust.com]
> On the issue of whether 6 months from August 31 should be taken as
> March 2 or February 28/29, I see the point you are making, but Im
> not sure. I
> tried turning it around and looking for the date 6 months
> prior to August
> 31, and I realised that all of our schemes fail to find such
> a date except
> the 182 day rule which would set it at March 2!
Just as a matter of interest, Microsoft Excels EDATE() function takes the approach you suggest Doyen: The month is modified by the number specified, the day remains the same unless it would be too great for the target month, in which case it is wound down. Consequently 6 months after August 31, 2001 is February 28, 2002, and 6 months before August 31, 2001 is February 28, 2001, but 6 months after February 28, 2001 is August 28, 2001!
Best Regards,
Ken
Ken Wallis
Empower Data Solutions Pty Limited
Blue Mountains, Sydney, Australia
Envision, enable, enhance, ... Empower
> > From: Klein Doyen T [mailto:Klein.DT@edreyfus.com]
>
> > I suppose its a matter of opinion/application but I like my idea
> > better. The month number is always 6 larger, and if it ends up
> > greater than the last
> > day of them month, you decrement to make sure the month never
> > increases by
> > 7. I say this because the original poster posed the problem
> > in terms of 6
> > months, not 180 days.
> >
> > 8/29 = 2/29 (or 2/28 in a non-leap year)
> > 8/30 = same
> > 8/31 = same
> > 9/1 = 3/1
> On the issue of whether 6 months from August 31 should be taken as
> March 2 or February 28/29, I see the point you are making, but Im
> not sure. I
> tried turning it around and looking for the date 6 months
> prior to August
> 31, and I realised that all of our schemes fail to find such
> a date except
> the 182 day rule which would set it at March 2!
Just as a matter of interest, Microsoft Excels EDATE() function takes the approach you suggest Doyen: The month is modified by the number specified, the day remains the same unless it would be too great for the target month, in which case it is wound down. Consequently 6 months after August 31, 2001 is February 28, 2002, and 6 months before August 31, 2001 is February 28, 2001, but 6 months after February 28, 2001 is August 28, 2001!
Best Regards,
Ken
Ken Wallis
Empower Data Solutions Pty Limited
Blue Mountains, Sydney, Australia
Envision, enable, enhance, ... Empower
> > From: Klein Doyen T [mailto:Klein.DT@edreyfus.com]
>
> > I suppose its a matter of opinion/application but I like my idea
> > better. The month number is always 6 larger, and if it ends up
> > greater than the last
> > day of them month, you decrement to make sure the month never
> > increases by
> > 7. I say this because the original poster posed the problem
> > in terms of 6
> > months, not 180 days.
> >
> > 8/29 = 2/29 (or 2/28 in a non-leap year)
> > 8/30 = same
> > 8/31 = same
> > 9/1 = 3/1