Hmmm. The IBM Web site is wrong.
Here is what they want:
ZONE('CET-1CEST,M3.5.0,M10.5.0')
Gives the correct value:
16308 21:26:52.293 CZA0216I MODIFY processing completed
9:29 PM
Thursday, November 3, 2016 (GMT+1)
Time in Paris, France
Without the dates it is in fact one hour off.
Charles
-----Original Message-----
From: Charles Mills [mailto:[email protected]]
Sent: Thursday, November 03, 2016 1:14 PM
To: 'IBM Mainframe Discussion List'
Subject: RE: Question on TZ and European time change
Thanks much. That gives me two things to tell the customer to look at.
Is the D in CEDT in your post a typo or are you looking at a different IBM
recommendation than I am?
Does anyone happen to know what the default date is if you specify the short
form CET1CEST rather than the long form CET1CEST,M3.5.0,M10.5.0?
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [ <mailto:[email protected]>
mailto:[email protected]] On Behalf Of John McKown
Sent: Thursday, November 03, 2016 12:50 PM
To: <mailto:[email protected]> [email protected]
Subject: Re: Question on TZ and European time change
On Thu, Nov 3, 2016 at 2:32 PM, Charles Mills < <mailto:[email protected]>
[email protected]> wrote:
> Thanks @John, good points that I failed to cover in my OP.
>
> The application runs POSIX(ON) (hence my reference to TZ [no
> underscore]) and yes, issues the code below with no error reported.
>
> int seRes = 0;
> seRes = setenv("TZ", Time_TZset.c_str(), 1);
> if (seRes != 0) Msg::Print(&Msg::Msgs[260], strerror(errno)); //
> "160E Error returned from setenv(\"TZ\"); time functions may not work
> correctly: %1$s
>
> Charles
>
>
I wrote up a Q&D C program on a z/OS 2.2 system. The output shows:
:JOARMC:/u/joarmc/junk$
./test-time
rc=0 timeval=Thu Nov 3 14:44:07 2016
rc=0 timeval=Thu Nov 3 14:44:07 2016
:JOARMC:/u/joarmc/junk$
./test-time
rc=0 timeval=Thu Nov 3 14:44:23 2016
rc=0 timeval=Thu Nov 3 14:44:23 2016
:JOARMC:/u/joarmc/junk$
TZ=CET-1CEST,M3.5.0,M10.5.0 ./test-time
rc=0 timeval=Thu Nov 3 20:44:27 2016
rc=0 timeval=Thu Nov 3 20:44:27 2016
:JOARMC:/u/joarmc/junk$
TZ=CET-1CEST ./test-time
rc=0 timeval=Thu Nov 3 21:44:36 2016
rc=0 timeval=Thu Nov 3 21:44:36 2016
Note that I got the TZ=CEST-1CEDT,M3.5.0,M10.5.0 from the IBM site:
<http://www.ibm.com/support/knowledgecenter/SS2RWS_1.11.0/com.ibm.zsecure.doc_1.11/zsec111_install104.html>
http://www.ibm.com/support/knowledgecenter/SS2RWS_1.11.0/com.ibm.zsecure.doc_1.11/zsec111_install104.html
Using the TZ above got what appears to be the correct answer.
What I think this means is that whatever is determining the "switch over"
date on z/OS UNIX is not set up correctly.
The code I used is:
#define _LARGE_TIME_API
#define _ALL_SOURCE
#define _POSIX
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <sys/time.h>
int main(int argc, char *argv[]) {
struct timeval64 tp1;
struct timeval64 tp2;
int rc;
rc=gettimeofday64(&tp1,NULL);
printf("rc=%d\ttimeval=%s\n",rc,ctime64(&tp1.tv_sec));
tzset();
rc=gettimeofday64(&tp1,NULL);
printf("rc=%d\ttimeval=%s\n",rc,ctime64(&tp1.tv_sec));
}
--
Heisenberg may have been here.
Unicode: <http://xkcd.com/1726/> http://xkcd.com/1726/
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
<mailto:[email protected]> [email protected] with the message:
INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
