Re: Does environment variable QIBM_QBASEYEAR affect timestamp variables?

[Rob Berendt <robertowenberendt@xxxxxxxxx>]

The highest timestamp to give you the error is ending_timestamp
=> '9990-12-09-16.45.15.934719'
After that, it simply doesn't return any data.
I connected to a different lpar and had the same results.
Of course, I had to change the journal receiver name.

On Wed, Apr 5, 2023 at 8:07 AM Rob Berendt <robertowenberendt@xxxxxxxxx>
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'
>          )) ;