LIST FILES | Hackers Guide to Visual FoxPro 7.0

Sys(1), Sys(10), Sys(11)

To everything there is a purpose, and a time to everything under heaven.

Ecclesiastes

If you are like us and never had a need to use the Julian date system, you've probably assumed that it was named for some dead Roman emperor, Julius somebody, and was based on some arcane mythology or astrological event. Not so, bucko.

While many of us prefer to count the days, weeks, fortnights, months and years as they go by, some scientists prefer to just have a serial number to distinguish today from yesterday, this night from one a hundred days ago. They may have a point. Joseph Scaliger in 1582 devised a numbering scheme based on the intersection of three major cycles: the 28-year solar cycle, the 19-year lunar cycle and the 15-year indiction cycle (the tax period used in the Ancient Roman Empire) and determined that the last date on which all these cycles started on the same date was January 1, 4713 B.C., and therefore called this Julian Day One. He named it Julian after his father, Julius. And we've been counting ever since.

At least that's one story we've read. Another is that these are sequential numbers since the date of the Great Flood. Since we weren't around for either of these events, we're not too worried about the truth of them, just what FoxPro can do with these numbers.

The Visual FoxPro facility for dates, as we mentioned in "DBF, FPT, CDX, DBC—Hike!" is accurate only back to 1752. The FoxPro help file cautiously points out that this is true only in the United States. We suspect it is also as accurate in the British Empire and former colonies, but know it took the Russian Revolution of 1918 to bring that region into compliance. If you're implementing an application outside the U.S. and need historical accuracy, you'd be wise to consult your neighborhood chronologist.

So the Julian numbering scheme may be a good way to get around all these local squabbles about what day it is. For dates in the distant past, though, you may need to devise your own algorithm, but once it's created, math on those numbers will be accurate against the values returned by these functions.

Usage

cDateJ = SYS( 1 ) cJtoC = SYS( 10, nExpression ) cDtoJ = SYS( 11, dExpression | tExpression | cExpression )

SYS(1) returns a character string containing the Julian number of today's date, sort of a DATEJ() function.

SYS(10) converts a numeric Julian number to a character string that looks an awful lot like a date, so it could be called JTOC(). While this function accepts arguments as low as 1,721,119 (which returns the silly string of 03/00/0000), it makes no allowance for the vagaries of the Gregorian calendar and is not accurate before the last zigzag of that counting method—September 14, 1752 for the U.S. and the British Empire.

SYS(11) converts a date or a datetime or a character string that looks like a date to a string containing the equivalent Julian number, so we'd make this into both the DTOJ() and TTOJ() functions. This is a pretty robust function, converting numbers with and without preceding zeroes without a complaint, digesting the entire assortment of standard date delimiters—slashes and dashes and dots—as well as the current SET("MARK") without a noise, but it does barf on a string containing both the date and time, such as the string returned by TTOC(). However, with all the other expressions that SYS(11) can convert correctly, you should be able to convert pretty much anything to a format acceptable by this function.

Conversions respect the settings of SET CENTURY, SET DATE and SET MARK TO, so don't assume a positional value or length unless you've explicitly set those settings beforehand.