Why does localtime() call tzset() but localtime_r() not?

Robbin Kawabata Robbin.Kawabata at sun.com
Fri Jan 18 17:09:14 UTC 2008

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."


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.

    localtime, localtime_r - convert a time value to a broken-down local time
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. 

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 

> Date: Fri, 11 Jan 2008 14:59:45 -0800
> From: Paul Eggert <eggert at CS.UCLA.EDU>
> Subject: Re: Why does localtime() call tzset() but localtime_r() not?
> To: tz at lecserver.nci.nih.gov
> Cc: Time Zone Mailing List <tz at lecserver.nci.nih.gov>
> "Jonathan Leffler" <jonathan.leffler at 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.

More information about the tz mailing list