HP3000-L Archives

September 2004, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Greg Stigers <[log in to unmask]>
Reply To:
Greg Stigers <[log in to unmask]>
Date:
Thu, 9 Sep 2004 23:03:03 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (27 lines)
Quoting Paul Christidis <[log in to unmask]>:
> Then its just a matter of keeping the 'holiday' file current.  Which would
> be easier than keeping the code, below, current.
I don't follow. Assuming that a company fairly consistently takes the same set
of holidays each years, following reasonable rules consistently, I would think
that my command file would continue to work until those holidays or their rules
change. For instance, because of our line of business, we do not take the day
after Thanksgiving. Should that ever change, then I add two lines to the
command file. And so on. Whereas, while one could admittedly build a file such
as you suggest for the rest of this century (or have an appropriate set of
fourteen files for the fourteen permutations of our calendar), you would still
be subject to the same issue, changing the controlling file when company policy
changes.

I don't see how my command file would need to be changed under any circumstances
that would not also affect your holiday file. That said, I have considered
exactly the approach you describe as being both idiot-proof and much simpler to
test.

Does anyone else handle their own scheduling without the benefit of third-party
products? How do you handle holidays?

Greg

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2