IBM i Global

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'
         )) ;

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'
         )) ;

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'
         )) ;