Re: Does environment variable QIBM_QBASEYEAR affect timestamp variables?

Hi Peter


I have similar questions. We are seeing one scenario where the service seems to use the 100-year window even when timestamps are specified. Maybe this is an artifact of how the DSPJRN command works, I might ask one of my IBM contacts about this.


I did a little testing this morning - we are at 7.3 - I tried some SQL functions to convert dates on both of the window boundaries - like 1/1/39 or 1/1/40 or 1/1/70 or 1/1/69 - all came in this century. So I don't have time to do more right now. The CVTDAT command might be a better test tool, maybe one of the CEE date APIs. I want to verify Rob's interpretation (all releases now use the 1970 window) one way or the other, I know I'm not sure of my interpretation (all releases use the 1940 window unless the environment variable is set for 1970, and that's only in 7.5)


Besides, I have COMMON presentations to get ready - and that's coming up soon, right?


Cheers
Vern


On Wed, 5 Apr, 2023 at 12:33 PM, Peter Dow <petercdow@xxxxxxxxx> wrote:


To: midrange-l@xxxxxxxxxxxxxxxxxx

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<mailto:petercdow@xxxxxxxxx>
tpdow@xxxxxxxxxxxxxx<mailto: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<http://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<http://3069-12-31-23.59.59.999999>' it worked fine.
If I used '3070-12-31-23.59.59.999999<http://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<http://3070-12-31-23.59.59.999999>'
)) ;