Subject: | Re: dates
| Date: | Tue, 9 Feb 2021 15:56:49 +0000
| From: | Michael Kennedy <Info@KennedySoftware.ie>
| Newsgroups: | pnews.paradox-dos
|
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! ;-)
>>
>
|