Re: Does environment variable QIBM_QBASEYEAR affect timestamp variables?

[VERNON HAMBERG Owner <vhamberg@xxxxxxxxxxxxxxx>]

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