You can also see all the date info at once with completedatestr(yourDate). There are some minor nits in Panorama’s conversion of dates. They might be Apple nits instead. Panorama appears to be using Julian Day numbers for date numbers and converting them to “dates” on a proleptic Gregorian calendar (extending that methodology back in time from its initial adoption on 10/15/1582).
Oddly the following evaluates to true:
the ‘latter’ date number should actually be the Gregorian adoption date of 10/15/1582, but PanX evaluates it as 10/10/1582.
The earliest date number PanX tries to ‘honestly’ evaluate with datepattern( is 1720245, aka Wed, Oct 8, -3, any earlier date number evaluates to ‘01/01/0’. And I’m not sure the ‘honest’ datepattern( conversion attempt is completely accurate for a few years thereafter.
Date( uses “Smart Dates,” some useful, shortcut, assumptions that you want a datenumber somewhere near the present. For old enough dates use datevalue( instead. For BC dates with that: 1BC is year 0, 2BC is year -1, etc. That works back to datenumber 1575023, 3/1/-400 aka 3/1/401 BC.
Now, relatively few PanX users will care about dates that far back. Certainly no one was using Gregorian back then; in fact Julius Caesar’s reforms from 46BC weren’t properly implemented for 50 years. Fewer yet will be affected by the limitations in PanX’s date math tools in antiquity. I don’t know if those are limitations Jim can, or even should, consider fixing. Someone concerned can learn about them in this post. They don’t bother me; I was just curious enough to see how far I could push the envelope. Except for the datenumber of Gregorian adoption, its datepattern conversion should be fixed if possible.