Note the latest Open Group localtime_r() man page excerpt below says localtime_r() should behave similarly to localtime() by calculating a time according to the timezone. Note the Change History description that on XSI systems, localtime_r() should set tzname, daylight, timezone - this is advisory, not mandatory; Change History is always advisory, and the word "should" (vs. "shall") is used.
From our standards person: "But, the normative text doesn't make it mandatory either. The way I read it, an implementation of localtime_r() is allowed to set tzname, but is not required to do so. If the implementation sets tzname, it is also allowed to set both daylight and timezone, but is not required to do so. If the implementation doesn't set tzname to match the converted time, it is not allowed to change either daylight or timezone."
From: http://www.opengroup.org/onlinepubs/000095399/functions/localtime.html The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition Copyright ? 2001-2004 The IEEE and The Open Group, All Rights reserved. NAME localtime, localtime_r - convert a time value to a broken-down local time ... DESCRIPTION ... The relationship between a time in seconds since the Epoch used as an argument to localtime() and the tm structure (defined in the <time.h> header) is that the result shall be as specified in the expression given in the definition of seconds since the Epoch (see the Base Definitions volume of IEEE Std 1003.1-2001, Section 4.14, Seconds Since the Epoch) corrected for timezone and any seasonal time adjustments, where the names in the structure and in the expression correspond. [Option End] [TSF] [Option Start] The same relationship shall apply for localtime_r(). [Option End] <<== ... [TSF] [Option Start] The localtime_r() function shall convert the time in seconds since the Epoch pointed to by timer into a broken-down time stored in the structure to which result points. The localtime_r() function shall also return a pointer to that same structure. TSF If the reentrant version does not set tzname, it shall not set daylight and shall not set timezone. ... CHANGE HISTORY ... Issue 6 ... IEEE Std 1003.1-2001/Cor 2-2004, item XSH/TC2/D6/56 is applied, adding a requirement that if localtime_r() does not set the tzname variable, it shall not set the daylight or timezone variables. On systems supporting XSI, the daylight, timezone, and tzname variables should all be set to provide information for the same timezone. This updates the description of localtime_r() to mention daylight and timezone as well as tzname. The SEE ALSO section is updated.
Date: Fri, 11 Jan 2008 14:59:45 -0800 From: Paul Eggert <eggert@CS.UCLA.EDU> Subject: Re: Why does localtime() call tzset() but localtime_r() not? To: tz@lecserver.nci.nih.gov Cc: Time Zone Mailing List <tz@lecserver.nci.nih.gov>
"Jonathan Leffler" <jonathan.leffler@gmail.com> writes:
I guess the POSIX manual allows this
POSIX is incoherent in this area. It places hardly any requirements on localtime_r; for example, localtime_r can be an alias for gmtime_r.
I think the intent is that localtime_r have read-only access to the internal data that tzset initializes. However, there's no clear POSIX requirement on the application to call tzset before calling localtime_r, nor there is any requirement on the implementation to behave as if tzset were called before execution begins.
Since the standard is fuzzy in this area, portable code should invoke tzset (or localtime or mktime or strftime) before invoking localtime_r.