Date: Thu, 15 Feb 2007 13:29:39 +1100
Reply-To: "Johnson, David" <David.Johnson@CBA.COM.AU>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Johnson, David" <David.Johnson@CBA.COM.AU>
Subject: Re: SAS Holidays
Content-Type: text/plain; charset="us-ascii"
For completeness:
I was browsing for Rick Langston's item posted on the date epoch for a
question from a colleague and also found this in the FAQs.
http://support.sas.com/faq/018/FAQ01802.html Given the US is changing
daylight saving next year, I presume this will either be withdrawn or
amended. It provides calculations for certain US holidays and daylight
saving.
I also found this small chunk of data for the UK and years 2005 - 2008,
and a note that says "DTI website", not "DLI" as I think I had earlier.
From the layout I suspect it is a direct copy and paste from the site,
and the code to import it was written around what becomes an awkward
layout when you remove the HTML table.
New Year's Day
3 Jan 2 Jan 1 Jan 1 Jan
Early May Bank Holiday
2 May 1 May 7 May 5 May
Spring Bank Holiday
30 May 29 May 28 May 26 May
Summer Bank Holiday
29 Aug 28 Aug 27 Aug 25 Aug
Christmas Day
27 Dec 25 Dec 25 Dec 25 Dec
Boxing Day
26 Dec 26 Dec 26 Dec 26 Dec
I recall too that I had a trap set in a piece of code I delivered a
couple of years ago. While certain days were fixed, or could be
calculated (like Easter), there was a portion that included the gazetted
exceptions and extras such as those above. In my batch process the
holiday table was analysed and when four or fewer gazetted dates
remained in the table for the future, the schedule reporting threw out a
warning that an update was due. The warning became insistent at 2 and
aborted the batch at 0. So, the process can be stabilised.
Kind regards
David
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
Peter Crawford
Sent: Wednesday, 14 February 2007 8:03 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: SAS Holidays
so, with multiple concerns and requirements, I see no simple
implementation that applies to _all_.
Sure, a multi-flagged table of non-working-day dates may be assembled.
However, as David Johnson points out, it will become a continuous
management problem. In that situation, there is no point keeping the
information (who cares what the forecast was last year, except those who
buy forecasts, and then only to prove or improve their investments in
forecasts). My expectation would be that not only the do new exceptions
have to be added, but also the range of flags (exception types) will
need to be able to be extended. Then applications also need to become
extensible to support more processes that respect their interest in
these exceptions.
It all sounds a bit too unstable.
When these exception handling processes are implemented, how stable is
the solution?
The past is stable, but not our interpretation ~ even there, problems.
Future events add the uncertainty of reality.
So, if we are still trying to build a design spec for a functional
solution, what are the specifics?
data/metadata
date, flag
(keyed on date and flag)
flag, flag_descriptions
(keyed on flag )
process
for my application, I use flag=28 because these are working day
exceptions for Peter Crawford
for yours, you may even want the union of more than one flag
(all national holidays in just any of a set of countries)
In general I want to exclude from programs and processes, not only data,
but also metadata (use some kind of metadata server).
So it seems difficult to satisfy that preference even for
application-specific "working days".
Any business/project/application will define it's own rules for this
kind of problem.
So, back to the original poster.
>> >From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
>> >bubba
>> >Sent: Wednesday, 14 February 2007 9:54 AM
>> >To: SAS-L@LISTSERV.UGA.EDU
>> >Subject: SAS Holidays
>> >
>> >Good afternoon,
>> >
>> >I'm trying to subtract two different dates from each other excluding
>> >weekends and holidays.
>> >
>> >I was able to use the intck('weekday12', start, end) function to get
>> >week days but I can't figure out removing holidays.
Solution Proposed
Keep a sufficient list of holidays in a table. You may want to exclude
weekend holidays.
Scan your holiday list table from start_date to end_date counting those
"holidays" which are not weekend days.
Deduct this from the intck( 'weekday12', start_date, to_date ) result
I hesitate to suggest the exclusion of weekend holidays even from the
application-specific list, because the information has more general
appeal, and it won't be long before it supports applications that need
holidays defined that occcur on weekend, too! I think sharing this kind
of meta-data is more important than a little complexity in code.
The only contention left is in the subject line at:
"SAS Holidays"
Probably the SAS System is used so widely,
every day is a holiday ~ somewhere !
This represents a lot of opinion and sometimes these opinions may be
presented a fact.
I hope you'll find it informative.
Peter Crawford
Crawford Software Consultancy Limited
On Tue, 13 Feb 2007 22:57:10 -0800, David L Cassell
<davidlcassell@MSN.COM> wrote:
>peter.crawford@BLUEYONDER.CO.UK sagely replied:
>>
>>a global problem of "bank holidays" is that they are really "local"
>>On this small island (UK) there are 3 or 4 sets. I cannot imagine how
>>many "local" holidays there are in each of China/India/Russia/ USA and
>>not forgetting across Europe, Australasia, Africa and South
>>America.....
>>
>>So I guess it needs something more than a simple interval name.
>>
>>Perhaps one could provide an "application-specific" list in a
>>holidays_table and use sql, like :
>> well, something like (untested code)
>>
>>select (
>> intck( 'weekday12', a.from, a.to_date )
>> - ( select count(*) from holidays_table
>> where holiday_date between a.from
>> and a.to_date
>> and weekday( holiday_date ) between 2 and 6
>> )
>> ) as maybe_working_days
>> from underlying_data a
>>
>>
>>If the above theory is feasible, I expect you will want to put that
>>holidays_table into memory with a sasfile statement.
>>
>>
>>At a recent banking client, I enquired about their policy on "working
>>days". Imagining something sophisticated and certainly complex (
>>because they operate credit and debit cards across at least 3
>>differing sets of "bank holidays" in UK), I was almost disappointed by
>>the practical simplicity they adopt ...
>> .... ignore bank holidays,
>> .... pay no special attention to irregular religous festival days
>> .... ignore local holidays
>>their rule is basic....
>>
>>if it isn't a Saturday or Sunday, then it is a working day !
>>
>>Well, at least it is straightforward and predictable.
>>
>>
>>In what circumstances are "working days" properly defined, _before_
>>they occur?
>>
>>I contend that it is irrelevant to apply any "working days" rule in a
>>commercial context.
>>
>>UK motorists used to get free on-street parking on a Sunday, because
>>it was not considered a "working day". UK used to have "Sunday
>>Observance" laws, but the march of commerce has liberalised these (to
>>just Easter!). So now the logic of parking rules, means that the
>>single yellow line (no parking during the working day) applies also on
>>Sunday !
>>
>>The concept of "working days" can apply to history, because "it has
>>happened". However, I see no prospect of generating a stable
>>calculation to predict future "working days" any more than we can
>>predict what politicians may decide !!!!!
>>
>>Peter Crawford
>>
>>P.S.
>>David H. J.
>>
>>Weekday12W would be one weekday interval treating Sunday and Monday as
>>weekend days.
>>
>>Weekday12 is the multi-unit interval 12 weekdays which treat Saturday
>>and Sunday as weekend days. So it is like 2 two weeks and 2 days i.e.
>>16 days except when more than one weekend falls among the 12 weekdays.
>>
>>
>>Peter C
>>
>>
>>
>>On Wed, 14 Feb 2007 10:25:26 +1100, Johnson, David
>><David.Johnson@CBA.COM.AU> wrote:
>>
>> >Are you sure the correct syntax is "Weekday12"? I remember this as
>> >"Weekday17W".
>> >
>> >Since Sunday is weekday 1 in SAS, I find it hard to believe that
"12"
>> >can be correct.
>> >
>> >I was writing this originally in V6, and the IntCk functions may now
>> >honour "Weekdaynn" but I would recheck the syntax nonetheless.
>> >"Weekday17" certainly did not work last century.
>> >
>> >
>> >As to your question, I'm afraid the only solution I ever found was
>> >to maintain a table of Bank Holidays and then identify whether these
>> >were compassed within a period.
>> >
>> >When I first wrote this some years back I used a macro to apply the
>> >dates in sequence and decrement the period.
>> >
>> >Thinking on it now, I would find the first and last dates in the
>> >sequence using SQL, select the records in my bank holidays table
between
>> >those dates (ensuring I ignored any recorded bank holidays on
>> >Saturday or Sunday), count the holiday records and decrement the
>> >period accordingly.
>> >
>>
>> >Kind regards
>> >
>> >David
>> >
>> >
>> >-----Original Message-----
>> >From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
>> >bubba
>> >Sent: Wednesday, 14 February 2007 9:54 AM
>> >To: SAS-L@LISTSERV.UGA.EDU
>> >Subject: SAS Holidays
>> >
>> >Good afternoon,
>> >
>> >I'm trying to subtract two different dates from each other excluding
>> >weekends and holidays.
>> >
>> >I was able to use the intck('weekday12', start, end) function to get
>> >week days but I can't figure out removing holidays.
>> >
>> >If anyone has any thoughts please let me know.
>> >
>> >bubba
>> >
>
>As far as I know, this is on a state-by-state basis, with different
>state legislatures sometimes voting in (or out) different holidays.
>So the definition of 'holiday' becomes critical.
>
>David
>--
>David L. Cassell
>mathematical statistician
>Design Pathways
>3115 NW Norwood Pl.
>Corvallis OR 97330
>
>_________________________________________________________________
>Get in the mood for Valentine's Day. View photos, recipes and more on
>your Live.com page.
>http://www.live.com/?addTemplate=ValentinesDay&ocid=T001MSN30A0701
************** IMPORTANT MESSAGE *****************************
This e-mail message is intended only for the addressee(s) and contains information which may be
confidential.
If you are not the intended recipient please advise the sender by return email, do not use or
disclose the contents, and delete the message and any attachments from your system. Unless
specifically indicated, this email does not constitute formal advice or commitment by the sender
or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries.
We can be contacted through our web site: commbank.com.au.
If you no longer wish to receive commercial electronic messages from us, please reply to this
e-mail by typing Unsubscribe in the subject line.
**************************************************************
