LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (February 2007, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Thu, 15 Feb 2007 14:41:57 +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"

One of last nights patches on my machine made daylight saving changes for the US.

I haven't seen a patch for WA yet, perhaps their staged implementation and trial is rather too hard to manage in patches.

Kind regards

David

/* - - - - - - - - - - - - - - - - - - - - - It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. -Sir Arthur Conan Doyle - - - - - - - - - - - - - - - - - - - - - */

-----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Howard Schreier <hs AT dc-sug DOT org> Sent: Thursday, 15 February 2007 2:26 PM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: SAS Holidays

On Thu, 15 Feb 2007 13:29:39 +1100, Johnson, David <David.Johnson@CBA.COM.AU> wrote:

>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,

It's not next year, it's three weeks from this Sunday.

http://www.infoplease.com/spot/daylight1.html

I suppose that Microsoft has taken care of that for those of use who download patches, but I know I'm going to have a headache with my VCRs, which up till now have been adjusting automatically.

>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. >**************************************************************

************** 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. **************************************************************


Back to: Top of message | Previous page | Main SAS-L page