On 09/02/2021 15:06, Steven Green wrote:
> so ground zero is 1/1/1900..

Yes, Steve, but only if a 1/2-digit year is submitted (0-99), or if the 
year has 3/4 digits of 0/00. "19" is always assumed. And the "19" is 
discarded on outputs.

If a year of 18xx, 17xx, 20xx, 21xx, 1xx, 9xx, etc is submitted, then 
the supplied century is accepted, retained, displayed...

   - M




> "Bernie van't Hof"  wrote in message 
> news:6021dfcb@pnews.thedbcommunity.com...
> 
> I liked your comment re generated dates.
> 
> As you say 0 to 99 are problematic as they will be cast into 20th or
> 21st century.
> 
>> 9999 can't be entered and display is truncated, but ~sometimes~ can be
> generated and stored eg
> 
> [] = DATEVAL("31-Dec-9999") + 1
> 
> But these fail:
> 
> DATEVAL("1-Jan-12345")            wants DATE
> [] = DATEVAL("1-Jan-12345") + 1   wants ALPHNUMERIC
> 
> And as "we" have nothing better to do today:
> 
> DATEVAL("1-Jan-0001") - 1               31-Dec-0
> DATEVAL("1-Jan-0001") - 367             30-Dec-1899
> DATEVAL("1-Jan-0001") - 367 + 100*366+1 16-Mar-2000
> 
>>
>> Just to clarify some of yesterday's notes, I think the Date-values for 
>> the first century (0000-0099) can be generated only internally, via 
>> Date-operations, because I think any attempt to input raw dates 
>> xx/xx/0000 to xx/xx/0099 will be forced into the 1900-1999 range.
>>
>> And, if we had nothing better to do!, we could then use further date 
>> arithmetic to calculate dates PRIOR to 31.12.0000, and we could see 
>> what PDoxDOS thinks of those!  ;-)
>>
>