Date math again...
Joe Chasan
joe at magnatechonline.com
Wed Jan 4 18:27:06 PST 2006
On Wed, Jan 04, 2006 at 08:57:29PM -0500, Bob Stockler wrote:
> John Esak wrote (on Wed, Jan 04, 2006 at 06:23:35PM -0500):
>
> | Joe's off-the-top was pretty good. I thought about it for a moment and said
> | to myself that would be too hard to work out let alone explain it. :-) Very
> | good.
> |
> | Ken's... I put in my "keep" folder and will be thinking about it still when
> | ever I go back to find it again. :-) I hear 7x + y and think, uh-oh,
> | quadratic equations again! :-) No, seriously, another great idea.
> |
> | Unfortunately, everyone is right about the holidays. Just put them in t
> | lookup file and check if any of the lookup file "dates" fall between or
> | equal to the start date and end date. Checking a hard coded array or
> | variable list would be clumsy and slower I think then one quick lookup...
>
> I've been playing with it a bit myself, and think that a lookup
> to a holidays file would be more expensive that a gosub to a
> subroutine (every date checked that is not a Sat or Sun would
> require a lookup, and require maintaining two different files).
>
> I visualize the whole thing as being a CALLed table that has only
> to be edited once a year (sometime after the following year's
> calendar is available - cron could bug the programmer as to when).
>
> The called table checks the DOW() if the day-of-the-week is Sat
> or Sun, and then, if not, a gosub in it checks in a subroutine in
> it to see if the date being checked is a non-work day.
>
> If: Day eq "02/20/2006" ' Presidents' Day (moveable)
> Then: YesNo = "1" ; return
> If: Day eq "05/30/2006" ' Memorial Day (fixed)
> Then: YesNo = "1" ; return
> If: Day eq "07/04/2006" ' Indepenence Day (fixed)
> Then: YesNo = "1" ; return
> ...
> Then: YesNo = "" ; return
>
> I think that would be a lot less expensive of programmer (and CPU)
> time, involving programmer time but once a year and much less CPU
> and HD time doing lookups.
sorry to disagree - and as a programmer lord knows i shouldn't thumb
my nose at a lifetime of revenue from such fodder, but i just don't
think things like that should be hardwired in process tables, regardless
of the cost in CPU cycles.
what happens when programmer retires/dies/disappears/gets in disagreement
with management, etc? will filePro have to lose one of their shrinking
customer flock just because no filePro programmers can be found in time?
--- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
-Joe Chasan- Magnatech Business Systems, Inc.
joe at magnatechonline.com Hicksville, NY - USA
http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
More information about the Filepro-list
mailing list