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