zTPF c localtme function

This can be done by specifying the DST information in the environment variable setting itself:

setenv("TZ", "CET-1CEST,M3.5.0,M10.5.0/3", 1);

Here is a description of the timezone setup instructions.

http://man7.org/linux/man-pages/man3/tzset.3.html
http://man7.org/linux/man-pages/man5/tzfile.5.html

The developer researching this requirement reports the following:

I was ably to get the program to run properly if I specify the DST information in the environment variable setting itself:

setenv("TZ", "CET-1CEST,M3.5.0,M10.5.0/3", 1);

I'm wondering if that would have sufficed for the customer.


With that said other platforms, like Linux have Files that reside under /usr/share/zoneinfo, which has this information already stored. We would need to enable this logic for z/TPF CISO and load these files, which we would need legal clearance for. It's about 1PM effort at most. Mostly for testing and possible debugging the newly enabled code.

Here is a description of the timezone setup instrcutions.

http://man7.org/linux/man-pages/man3/tzset.3.html
http://man7.org/linux/man-pages/man5/tzfile.5.html

Please let us know if this satisfies your request.

Yes, the timezone is always the same

There exist features in the Pico application [the Trenitalia reservation application] that require reprocessing of reservations that were made in the past. Normally the data that is most frequentlyused as a point of reference in time is the timestamp. Getting different results calling localtime with the same timestamp, depending on whether a different DST regulation has taken effect from one invocation to the next, introduces errors that could even produce erroneous accounting charges. A refund after departure, for example, is only granted after a maximum number of hours following train departure. If we find that we have to perform such an operation the day of a DST change we could have refunds that are not allowed being granted or vice versa.

It's very important that a standard api run fine in every scenario.

There are a lot of application scenario that can be affected by this problem especially if you are running around the DST change day. Be Linux compliant with such a standard C function it's a must from my point of view.

I'd like to clarify Paolo's request by rephrasing it:
Description: TPF running localtime does not support the same functionality as on linux.    We run a program that calls localtime for time stamps in the past. The problem is that it always returns the time with Daylight Savings applied, even for times such November when Daylight Savings was not in effect on our time zone (Central European). When we try to set the TZ variable, it only gives us the same Greenwich Mean Time (GMT). If we run a similar program on linux, the localtime function is able to detect when and when not to apply DST to timestamps in the past.    We would like to be able to determine the local time for any time stamp in the past, without having to write our own logic to decide when and when not to apply the Daylight Savings Time.

Use case:
Consider the following Sample Code, with and without setting the TZ environment variable:
#include
#include
#include
void QZZ5()
{
struct tm *ptrtm;
time_t tod;
int i=0;
tod=0x57000000;
setenv("TZ","CET",1);
for (i = 0; i < 2; i++) {
printf("--------- DATE AND TIME CONVERSION --------\n");
/**************************************************/
printf("-- DEFAULT TZ = %s\n",getenv("TZ"));
/**************************************************/
ptrtm = gmtime(&tod);
printf("gmtime --> %02d/%02d/%04d",
ptrtm->tm_mday,ptrtm->tm_mon+1,ptrtm->tm_year+1900);
printf(" - %02d:%02d:%02d DSTflag=%d\n",
ptrtm->tm_hour,ptrtm->tm_min,ptrtm->tm_sec,ptrtm->tm_isdst);
ptrtm = localtime(&tod);
printf("localtime --> %02d/%02d/%04d",
ptrtm->tm_mday,ptrtm->tm_mon+1,ptrtm->tm_year+1900);
printf(" - %02d:%02d:%02d DSTflag=%d\n",
ptrtm->tm_hour,ptrtm->tm_min,ptrtm->tm_sec,ptrtm->tm_isdst);
tod=0x56500000;
}
}

Here are the results if we run this program on z/TPF, which
are incorrect:

CSMP0097I 13.52.17 CPU-B SS-BSS SSU-HPN IS-01
--------- DATE AND TIME CONVERSION --------+
-- DEFAULT TZ = CET+
gmtime --. 02/04/2016 - 17:23:12 DSTflag=0+
localtime --. 02/04/2016 - 17:23:12 DSTflag=0+
--------- DATE AND TIME CONVERSION --------+
-- DEFAULT TZ = CET+
gmtime --. 21/11/2015 - 05:24:16 DSTflag=0+
localtime --. 21/11/2015 - 05:24:16 DSTflag=0+

Here are the results if we run a similar program on linux,
where the results are correct:

--------- DATE AND TIME CONVERSION --------
-- DEFAULT TZ = CET
gmtime --> 02/04/2016 - 17:23:12 DSTflag=0
localtime --> 02/04/2016 - 19:23:12 DSTflag=1
--------- DATE AND TIME CONVERSION --------
-- DEFAULT TZ = CET
gmtime --> 21/11/2015 - 05:24:16 DSTflag=0
localtime --> 21/11/2015 - 06:24:16 DSTflag=0
Time now is: Tue May 10 19:51:09 2016
Time in GMT is: Tue May 10 18:51:09 2016

Our TPF Clock settings are:
CLOCKS GDIF=-0100, X
LST=0100, X
DATE=04/01/02

AAES0008I 31 ==> zdcnf CMMLGD
DCNF0020I 09.38.29 CINFC LABEL CMMLGD ADDRESS - 0000000002405040
AAES0008I 31 ==> zdcor 02405040.40
DCOR0010I 10.13.43 BEGIN DISPLAY
0000000002405040- FF9C0000 00000000 00000000 00000000 ........ ........
0000000002405050- 08000000 00000000 00000000 00000000 ........ ........
0000000002405060- 00000000 FF000000 00000000 FF000000 ........ ........
0000000002405070- 00000000 FF000000 00000000 FF000000 ........ ........
END OF DISPLAY - ZEROED LINES NOT DISPLAYED

ZDTIM DST
DTIM0100I 17.49.14 DST SETTING IS ON
OFFSET - 60
MONTH ON- MAR
DAY ON- SUN
WEEK ON- 4
HOUR ON- 2 MINUTE ON 0
MONTH OFF- OCT
DAY OFF- SUN
WEEK OFF- 5
HOUR OFF- 3 MINUTE OFF 0
END OF DISPLAY