|Anonymous | Login | Signup for a new account||2017-09-19 20:43 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|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|
|User Reference||https://sourceware.org/bugzilla/show_bug.cgi?id=21229 [^]|
|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.|
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.|
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)
|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.)|
|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||=> https://sourceware.org/bugzilla/show_bug.cgi?id=21229 [^]|
|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|