I guess astronomers would vote for Julian Dates.
But I'm not sure that SAS needs another convention for *storing* dates (as
distinguished from recognizing and displaying them). I think one of those
There is nothing inherently Gregorian about the SAS convention for
*storing* dates. It is just the number of days elapsed since Cameroon
became independent of France (which happened 1 January 1960 on the
Gregorian calendar, 1 Tevet 5720 on the Jewish calendar, etc.). In
contrast, most of the SAS date functions, formats, and informats for
*manipulating* dates are specific to the Gregorian calendar.
There is also much room for confusion. SAS already has a format/informat
pair for dates named "JULIAN". These support a notation which concatenates
an ordinal day number DDD to a year number YYYY. For example, today is
2003180 and the next Cameroon independence day is 2004001. While this
construct is more or less calendar neutral (for example, it could be used
with the Jewish calendar), SAS has implemented it for the Gregorian
calendar. The documentation is, in my opinion, shaky. It refers to the
JULIAN informat performing a conversion *to* a Gregorian date, when in fact
it converts *from* a Gregorian date represented by a YYYYDDD string to a
calendar-neutral SAS date.
It could get worse. We have not discussed the Modified Julian Date, which
is a simple transformation of the Julian Date which Jack described, using a
date in 1858 as the origin. Nor has anybody proposed support for the Julian
*Calendar* (forerunner of the Gregorian, with the same months and dates but
with a 1:3 ratio between 366-day years and 365-day years, in contrast to
the Gregorian's 97:303).
Getting back to the original subject, I see no reason why SAS should not be
enhanced to recognize Gregorian dates before 1582. There is presumably
working code out there which depends on the current behavior. The usual
solution should suffice; that is, creation of a new system option
(RETROGREGORIAN/NORETROGREGORIAN; try saying that three times, fast), with
NORETROGREGORIAN as the default.
On Thu, 26 Jun 2003 13:24:37 -0600, Jack Hamilton
>Perhaps SAS Institute could support Julian Dates. The Julian Date is
>just the number of days since January 1, 4713 BC, and is used in
>astronomy to get around this very problem. There would have to be an
>associated set of functions to convert between Julian Date and the
>appropriate local calendar. November 22, 1799 in Denmark was 1 Frimaire
>VIII in France, and there's probably a SAS application using that
>information waiting to be written.
>Manager, Technical Development
>Metrics Department, First Health
>West Sacramento, California USA
>>>> "Thomasset Pierre" <pierre.thomasset@EURONET.BE> 06/20/2003 2:11 AM
>This is a summary of a subject discussed in SAS-L several times :
>Definition of a SAS date value :
>value that represents the number of days between January 1, 1960, and
>specified date. SAS can perform calculations on dates ranging from
>1582 to A.D. 19,900. Dates before January 1, 1960, are negative
>dates after are positive numbers.
>NB. the upper boundary for informat date. is 31Dec20000 (see test
>Typical explanation of the limitation in the past : the 'Gregorian
>calendar' was first introduced in 1582, in some countries. It used a
>method to compute the number of days per month. It was replacing the
>method, called 'Julian calendar'.
>Unfortunately, this does not explain why this new method could not be
>applied to the dates before Jan 1st, 1582. We can maybe imagine that
>documentation of the new method (does somebody have it ?) did only
>the calculation for the dates from 1582.
>Furthermore, this limitation creates problems, when using dates
>from other systems, such as an operational Cobol system (see test
>- dates before 1582, introduced in the other systems, cannot be stored
>SAS data warehouse,
>- some dates, with century '00' (1st century), are processed
>than dates with century from '01' to '15'. They are converted to valid
>dates, replacing century '00' by '19' or '20', while the other ones
>converted to invalid (missing) dates.
>The questions :
>1 - Should S.I. accept dates before 1582,
>1a - without modifying existing date formats / informats, then do you
>some problems with your existing applications, programs, formats,
>informats, data sets, ... ?
>1b - with introduction of new date formats and informats ?
>2 - Can we apply the 12 month / year, 365 or 366 day / year rules
>3 - Are age calculations valid before 1582 ?
>4 - Can we ignore such problems, as we ignore the weekdate. format
>in the early centuries of valid sas dates. ? see test program 3.
>Test program 1 :
>option nocenter ls= 69;
> do date= '31dec9999'd by 1 while (day (date)); end;
> datn= date - 1;
> put / date= 8. -L date ' last valid =' datn datn 9. /'.' ;
> do date= 0 by -1 while (day (date)); end;
> datn= date + 1;
> put / date= 8. -L date ' first valid =' datn datn 9. / '.' ;
> format date date9. datn worddatx. ;
> _error_= 0;
>NOTE: Invalid argument to function DAY at line 468 column 41.
>date=6589336 ********* last valid =31 December 20000 6589335.
>NOTE: Invalid argument to function DAY at line 474 column 31.
>date=-138062 ********* first valid =1 January 1582 -138061.
>Test program 2 :
> input @1 date_cobol $char8. @1 date_sas yymmdd8.;
> format date_sas yymmdd10.;
>options nonumber nodate nocenter;
>title 'Dates from Cobol';
>Dates from Cobol
>Obs cobol date_sas
>1 00011231 2001-12-31
>4 16011231 1601-12-31
>5 19011231 1901-12-31
>6 20011231 2001-12-31
>7 99011231 9901-12-31
>Test program 3 :
> input @1 datx $char9. @1 dat date9.;
> put datx '==>' dat weekdate.;
>01jan2000 ==> Saturday, January 1, 2000
>01jan1900 ==> Monday, January 1, 1900
>01jan1800 ==> Wednesday, January 1, 1800
>01jan1700 ==> Friday, January 1, 1700
>01jan1600 ==> Saturday, January 1, 1600
>01jan1582 ==> NOV, January 1, 1582