Re: Does environment variable QIBM_QBASEYEAR affect timestamp variables?

What I find odd is that

https://www.ibm.com/support/pages/node/6579221?mhsrc=ibmsearch_a&mhq=QIBM%26lowbar%3BQBASEYEAR

says

 "The current supported date range for t2-digit year date formats is January 1, 1940 – December 31, 2039. When using a date format that only includes the last two digits of a year, the system assumes years 40 to 99 are 1940 - 1999, and years 00 to 39 are 2000 - 2039."

But timestamps have a 4-digit year, so why does this apply to them?

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx
tpdow@xxxxxxxxxxxxxx

/
On 4/5/2023 5:07 AM, Rob Berendt wrote:

Environment: IBM i 7.5, TR 1, cume 22321, Hiper 22, db 3.

While looking at a different thread in which a gentleman tried to use all
inclusive timestamps to get beginning to end I noticed something odd.
He was using a sql service with parameters like
starting_timestamp => '0001-01-01-00.00.00.000000',
ending_timestamp => '9999-12-31-23.59.59.999999'
and it wasn't finding anything.
I suggested he just follow the doc for that function, leave those blank and
it would work. However I did delve into this further.
The starting timestamp was fine.
It was the ending timestamp.
If I used '3069-12-31-23.59.59.999999' it worked fine.
If I used '3070-12-31-23.59.59.999999' I would get
SQL State: 42616, Vendor Code: -443, Message: [SQL0443] ENDING_TIMESTAMP IS
EARLIER THAN STARTING TIMESTAMP
https://www.ibm.com/support/pages/node/6579221?mhsrc=ibmsearch_a&mhq=QIBM%26lowbar%3BQBASEYEAR
Will someone on an older OS which still supports this function try 2039
then try 2040?
select *
from table (qsys2.display_journal ('QSYS',
'QAUDJRN',
starting_receiver_name => 'Q633900051',
starting_receiver_library => 'QSYS',
ending_receiver_name => 'Q633900051',
ending_receiver_library => 'QSYS',
starting_timestamp => '0001-01-01-00.00.00.000000',
ending_timestamp => '3070-12-31-23.59.59.999999'
)) ;