Austin Group Defect Tracker

Aardvark Mark III

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001125 [1003.1(2016)/Issue7+TC2] Base Definitions and Headers Editorial Clarification Requested 2017-03-07 11:24 2017-03-07 16:02
Reporter Florian Weimer View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Florian Weimer
Organization Red Hat
User Reference [^]
Section strftime, strftime_l
Page Number unknown
Line Number unknown
Interp Status ---
Final Accepted Text
Summary 0001125: Do strftime, strftime_l set tzname, daylight, timezone?
Description The description for strftime says that “Local timezone information is used as though strftime() called tzset().” It does not specify whether the side effects that are normally associated with tzset (updates to the tzname, daylight, timezone variables) are observable by a caller to strftime or strftime_l.
Desired Action Change the sentence to:

“Local timezone information is used as though strftime() called tzset(). It is unspecified whether the tzname, [XSI] [Option Start] daylight, or timezone [Option End] variables are updated by a call to strftime().”
Tags No tags attached.
Attached Files

- Relationships

-  Notes
geoffclare (manager)
2017-03-07 15:52

The intention is that strftime() must update tzname[].

This was stated explicitly in POSIX.1-1990 and POSIX.1-1996 in section 8.1.1 after the description of the TZ rules:
Whenever ctime(), strftime(), mktime(), or localtime() is called, the time zone names contained in the external variable tzname shall be set as if the tzset() function had been called.

However, the merge with SUS in 2001 did not retain this statement with the TZ description in XBD, instead relying on the "as though" statements in the individual function descriptions.

There is also this statement in the tzset() APPLICATION USAGE section:
Since the ctime(), localtime(), mktime(), strftime(), and strftime_l() functions are required to set timezone information as if by calling tzset(), there is no need for an explicit tzset() call before using these functions. However, portable applications should call tzset() explicitly before using ctime_r() or localtime_r() because setting timezone information is optional for those functions.

Note that the "as though" wording on the strftime() page is exactly the same as on the localtime() page, and I assume nobody would question the requirement for localtime() to set tzname[]. Interestingly, the mktime() page has slightly different wording:
Local timezone information shall be set as though mktime() called tzset().

I suggest that we should change the localtime() and strftime() pages to use this wording.
Florian Weimer (reporter)
2017-03-07 16:02

It looks like an implementation could keep updating these variables, but never the read from them, so there wouldn't be a thread safety hazard for multi-threaded programs. (Especially if all internal uses of strftime etc. used variants of these functions which skipped the update of these global variables.)

- Issue History
Date Modified Username Field Change
2017-03-07 11:24 Florian Weimer New Issue
2017-03-07 11:24 Florian Weimer Name => Florian Weimer
2017-03-07 11:24 Florian Weimer Organization => Red Hat
2017-03-07 11:24 Florian Weimer User Reference => [^]
2017-03-07 11:24 Florian Weimer Section => strftime, strftime_l
2017-03-07 11:24 Florian Weimer Page Number => unknown
2017-03-07 11:24 Florian Weimer Line Number => unknown
2017-03-07 15:52 geoffclare Note Added: 0003611
2017-03-07 16:02 Florian Weimer Note Added: 0003612

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker