03-09-2012 02:01 PM
One of the datasets I am working with has julian dates. I am using the functions like this -
The query builder in EG is validating the function usage correctly but the output is like this -
Any suggestions as to get the correct output?
03-09-2012 02:22 PM
I don't think format matters.
put b / b date9.;
OP, please show some raw data of your julian dates, as you can see, I can't repeat your problem.
03-09-2012 03:07 PM
These values do not fit with a expected format for any definition of a julian date unless they are meant to be millenia in the future. It looks like you may be dealing with a unix style time counter possibly, although that would put all the dates in your example in the 1970's. What are your expected values for the data shown?
03-09-2012 03:18 PM
Thanks Friedegg, I see your point about the julian dates. My manager just forwarded me this link -
Either way, is there a funtion to get the appropriate mmddyy10. format? The dates are hospital admission/discharge dates around 2002-04.
03-09-2012 03:30 PM
I am very familiar with date systems, the JDN system, as I have mentioned does not fit this data. The values you have would represent dates thousands of years in the future since it is representing a count of 7 million plus days (over 19,000 years) from Nov. 24, 4714 BC
I can say quite confidently that these data elements you have shared here are absoluelty not Julian Dates repseneting Gregorian dates in and around April 2002.
03-09-2012 02:42 PM
This may be a case of mixed semantics. The term julian date has two meanings, unfortunately. One convention defines a julian date as a date in the format such as yy[yy]ddd such as 11001, which would be the first day or 2011 or 01/01/2011 would be your expected result. The more common, in my mind, definition of a julian date is the count of days from the julian epoch (jdn 0 or Nov. 24, 4714 BC). The Datejul function is expecting the definition I described first. If you data is like the second definition I used then you can convert to a sas date by simple subtraction: put(x-2436934.5,mmddyy10.);
03-09-2012 04:13 PM
If you can find the actual date associated with one of those numbers then you can adjust to use the base date that SAS uses.
Also I would look at the last 3 digits to see if the range is 001 to 366 (2004 was a leap year). If so it may be that the first 4 digits are some year coding scheme though your example would yield more than 3 calendar years.
03-22-2012 03:14 PM
So we looked up similar files on the mainframe. They all seem to have the 2004123 date whereas only the sas file we got has these 7447153 dates. Also, the last 3 digits do fall into the 1-366 range. So, there is something odd with the first 4 digits only.
03-22-2012 05:28 PM
So it looks like there may be an issue with reading the data from the mainframe. At which point how it was transferrec becomes a question as native dates seem to be a recurring issue with data conversions.
I would suggest getting the minimum data from the mainframe if possible. The compare the minimum value from you SAS data set. If the minimum is 2004XXX and the minimum in SAS is 7444xxx then the year would be the value of the first four digits in the SAS dataset - (7444-2004). Which gives us a
year= floor(<sasvar>/1000) - (7444-2004);
date= datejul( year*1000+days);