Re: Correcting AGE_INFO
Re: Correcting AGE_INFO
- Subject: Re: Correcting AGE_INFO
- From: Deivy Petrescu <email@hidden>
- Date: Fri, 05 Feb 2010 16:32:14 -0500
On 05/02/2010, at 14:20 , Mark J. Reed wrote:
> On Fri, Feb 5, 2010 at 10:53 AM, Deivy Marck Petrescu
> <email@hidden> wrote:
>> So, if current date is either a Saturday or Sunday, it will be moved to
>> Monday. It doesn't make much sense to me, but at the same time it does ???
>
> You're comparing two dates, and need to look at both. If all you have
> is the current date and the age in days (including weekends), then you
> should do the subtraction to figure out the first date.
>
> If the first (older) date is a Sat or Sun, you can move it up to the
> next Monday without changing anything since Saturdays and Sundays
> don't count.
>
> But if the second (newer, current) date is a Sat or Sun, moving it up
> to the next Monday will add an extra business day that hasn't happened
> yet. So you should instead move it backwards to the previous Friday.
>
I don't agree with this.
Obviously it all boils down to what the op wants... but if you ask me, if you move the day to Friday, you will incur in an error.
If the document was modified on Thursday and current day is Saturday, does it make sense that it has been one day since it was "modified"?
I assume if I am charging you for the service I'd put Monday, if I am paying I'd move it to Friday!
So, it is not dates, it is money....
:)
> Something like this code will yield the desired result - but it's inefficient:
>
> on count_business_days from startDate to endDate
>
> -- discount time of day differences
> copy {startDate, endDate} to {startDay, endDay}
> repeat with endPoint in {startDay, endDay}
> tell endPoint to set {its hours, its minutes, its seconds} to {0,0,0}
> end repeat
>
> set busDays to 0
> set curDay to startDay
> repeat while curDay <= endDay
> if curDay's weekday is not in { Saturday, Sunday } then
> set busDays to busDays + 1
> end if
> set curDay to curDay + 1 * days
> end repeat
> return busDays
> end count_business_days
>
> That's demonstrably correct, but as I said, inefficient.
> So the goal is to achieve the same results without having to iterate
> over all the days in between.
>
> My original thought, to divide to get whole weeks and multiply that by
> 5 and then count the remainder, is one way to do it. You still wind
> up with a loop, but it's a loop over no more than 6 days, no matter
> how far apart the two dates are, so the whole thing is O(1) instead of
> O(n). The trick lies in the adjustment, wihch is where I messed up in
> my first take.
>
> Here's a version that should yield the right results:
>
> on calc_business_days from startDate to endDate
>
> -- discount time of day differences
> copy {startDate, endDate} to {startDay, endDay}
> repeat with endPoint in {startDay, endDay}
> tell endPoint to set {its hours, its minutes, its seconds} to {0,0,0}
> end repeat
>
> -- handle reversed inputs
> if startDay > endDay then
> return -(calc_business_days from endDay to startDay)
> end if
>
> -- skip over leading or trailing weekends
> repeat while startDay's weekday is in {saturday, sunday}
> set startDay to startDay + days
> end repeat
>
> repeat while endDay's weekday is in {saturday, sunday}
> set endDay to endDay - days
> end repeat
>
> -- If the above loop made the days cross, they're
> -- in the same weekend.
> if startDay > endDay then
> return 0
> end
>
> set allDays to (endDay - startDay)/days
> set wholeWeeks to (endDay - startDay) div weeks
> set busDays to wholeWeeks * 5
>
> set lastWeek to startDay + wholeWeeks * weeks
> repeat while lastWeek <= endDay
> if lastWeek's weekday is not in { saturday, sunday }
> set busDays to busDays + 1
> end if
> set lastWeek to lastWeek + days
> end repeat
> return busDays
> end calc_business_days
>
>
>
> That final correcting loop could also be replaced by a computation,
> but it's a complicated one that's dependent upon the weekday position
> as well as the number of days left. There's an interesting pattern
> to it that could be turned into a formula, but it's a non-obvious
> formula and IMO best left as the straightforward loop.
Deivy Petrescu
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden