TZ-related changes in Draft 5 of the next POSIX standard
The Austin Common Standards Revision Group is drafting the next revision of POSIX, and Draft 5 (d5) is now available; see <http://www.opengroup.org/austin/>. Here are some tz-related changes in this draft: * The TZ string has been extended to allow time zone abbreviations with +, -, and digits, so long as the abbreviations are quoted by angle brackets. For example, the Bourne shell commands TZ='<UTC+10>-10' date; date -u might output the following text: Tue Jan 9 10:30:19 UTC+10 2001 Tue Jan 9 00:30:19 GMT 2001 * Conforming time zone abbreviations are no longer allowed to contain arbitrary characters. Unquoted abbreviations can contain only alphabetic characters in the current locale; quoted ones can also contain digits, '+', and '-'. * Multibyte characters are explicitly allowed in time zone abbreviations, e.g. TZ='AB@-10' might specify an abbreviation 'AB@-' if '@-' is a valid multibyte character in the current locale. * The following declarations are added to <time.h>: char *asctime_r(const struct tm *restrict, char *restrict); char *ctime_r(const time_t *, char *); struct tm *localtime_r(const time_t *restrict, struct tm *restrict); struct tm *gmtime_r(const time_t *restrict, struct tm *restrict); struct tm *getdate(const char *); char *strptime(const char *restrict, const char *restrict, struct tm *restrict); extern int daylight; extern long timezone; * The following declaration is added to <wchar.h>, as per ISO C99: size_t wcsftime(wchar_t *restrict wcs, size_t maxsize, const wchar_t *restrict format, const struct tm *restrict timptr); Here is the TZ-environment-variable-relevant part of the text that has changed; this covers the first three items mentioned above. I have included change bars in the text quoted below. The unchanged part appears in section 8.1.1 of the current POSIX standard. The expanded format (for all TZs whose value does not have a colon as the first character) is as follows: stdoffset[dst[offset][,start[/time],end[/time]]] Where: std and dst Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard (std) or the alternative (dst-such as Daylight Savings Time) timezone. Only std is required; if dst is missing, then the alternative time does not apply in this locale. | | Each of these fields may occur in either of two formats quoted or | unquoted: | | - In the quoted form, the first character shall be the less-than | ('<') character and the last character shall be the | greater-than ('>') character. All characters between these | quoting characters shall be alphanumeric characters in the | current locale, the plus-sign ('+') character, or the | minus-sign ('-') character. The std and dst fields in this case | do not include the quoting characters. | | - In the unquoted form, all characters in these fields shall be | alphabetic characters in the current locale. | | The interpretation of these fields is unspecified if either field is | less than three bytes (except for the case when dst is missing), | more than {TZNAME_MAX} bytes, or if they contain characters | other than those specified.
On Monday, January 8 2001, "Paul Eggert" wrote to "tz@elsie.nci.nih.gov" saying:
* The following declarations are added to <time.h>:
char *asctime_r(const struct tm *restrict, char *restrict); char *ctime_r(const time_t *, char *); struct tm *localtime_r(const time_t *restrict, struct tm *restrict); struct tm *gmtime_r(const time_t *restrict, struct tm *restrict); struct tm *getdate(const char *); char *strptime(const char *restrict, const char *restrict, struct tm *restrict);
extern int daylight; extern long timezone;
Is there any hope of their adding timegm() as well? -- Jonathan Lennox lennox@cs.columbia.edu
<<On Tue, 9 Jan 2001 12:26:23 -0500 (EST), Jonathan Lennox <lennox@cs.columbia.edu> said:
Is there any hope of their adding timegm() as well?
I doubt it. There are already problems with the existing definitions, and adding such an interface would probably make it even worse. One of the conflicting intents of the specification is that one could implement timegm() as a simple formula, an example of which is given in the ``Base Definitions'' under ``Seconds Since the Epoch''. That definition has been the source of much conflict over the history of the POSIX effort, and much of the traffic on the austin-group mailing-list last month arose from the same issue. I am told there are not supposed to be any new interfaces added at this point in the process, even if consensus could be reached. -GAWollman
--On Monday, January 8, 2001 16:31 -0800 Paul Eggert <eggert@twinsun.com> wrote:
* The following declarations are added to <time.h>:
char *asctime_r(const struct tm *restrict, char *restrict); char *ctime_r(const time_t *, char *); struct tm *localtime_r(const time_t *restrict, struct tm *restrict); struct tm *gmtime_r(const time_t *restrict, struct tm *restrict); struct tm *getdate(const char *); char *strptime(const char *restrict, const char *restrict, struct tm *restrict);
extern int daylight; extern long timezone;
A suggested clarification: localtime_r (and friends) should always be thread safe, even if a non-thread-safe time function such as mktime is called in another thread. - Chris
participants (4)
-
Chris Newman -
Garrett Wollman -
Jonathan Lennox -
Paul Eggert