That's because they're not that kind of Julian date (which I think is called the Julian daynumber). The numbers those VFP SYS() functions are returning is the number of days which have passed since some date around 4000 B.C.

The Julian daynumber (I think) is the type of number you were expecting with year plus days-in-year, e.g. - 1999048 for today. I don't think there's a function to return this number within native VFP commands and functions, but it'd be awfully easy to write. Something like:

FUNCTION JulDayNum
LPARAMETER ldDate
LOCAL lnRetVal, lnMonthNum
IF TYPE(ldDate) != 'D'	&& May also want to accept D/T
	RETURN 0	&& zero
ENDIF
lnRetVal = YEAR(m.ldDate)*1000
FOR lnMonthNum = 1 TO MONTH(m.ldDate) - 1
	* Add number of days for each month from an array
ENDFOR
lnRetVal = m.lnRetVal + DAY(m.ldDate)
RETURN m.lnRetVal

>VFP's 'Julian date' - I assume you refer to Julian system date - is SYS(1), which returns the value I showed: 2451227
>VFP's 'Julian day number' is SYS(10) is the same function, only for a given date, not the current system date, and returns the same value for today: 2451227
>
>Neither of these contain the year explicitly within the returned value.
>This is what's confusing...
>
>Mark
>
>>There's Julian date and Julian daynumber. One is number of days since a given date. Other is year plus days within a year as in your example. I can't remember which term applies to which, but it seems logical to me that daynumber would be the one which is year plus day within year. If you search the web for Julian, date, day, and number, you'll get a lot of "hits" with information.
>>
>>FoxPro stores dates internally as the number of days since a start date (somewhere around 4000 B.C., I forget). DateTimes are stored as that day number plus a decimal part representing how much of the day has passed.
>>
>>Hope some of this is what you wanted to know.
>>
>>Cheers,
>>Rich.