Details

[Home]

Issue of the Standard # S0561

Brief

Positive tm_isdst field for %z processing in strftime()

Detailed Description

POSIX-2008 (IEEE Std 1003.1-2008) states about %z conversion specifier of strftime():

Replaced by the offset from UTC in the ISO 8601:2000 standard format ( +hhmm or -hhmm ), or by no characters if no timezone is determinable. For example, "-0430" means 4 hours 30 minutes behind UTC (west of Greenwich). If tm_isdst is zero, the standard time offset is used. If tm_isdst is greater than zero, the daylight savings time offset is used. If tm_isdst is negative, no characters are returned.

But how say Carlos O`Donell:

There are two ways to interpret the wording in POSIX and what is stored in `struct tm`
Either:
(a) If tm_isdst is >0 then the values already stored in the broken down time had daylight savings applied.
or
(b) If tm_isdst is >0 then the values in the broken down time shall be adjusted by daylight savings when printed. That is to say that the values in the broken down time must *always* be the non-DST version of those values, with strftime applying the adjustment at the time of printing.
The POSIX wording doesn`t say what happens if you change the tm_isdst field, only that if it is >0 the DST-adjusted offset will be used, and if it is 0 the non-DST offset will be used.
The most logical and simplest implementation is that the the time in the broken down time is always the local time with DST applied, and if DST was applied then tm_isdst is >0 (ignoring tm_isdst <0 which is handled correctly).
The GNU C Library follows interpretation (a).
The LSB testsuite appears to follow interpretation (b).

Change glibc to follow (b) would break a lot of existing programs which would be forced to deal with a change in the stored offsets in the broken down time. So we fixed the test to follow interpretation (a).

Problem location(s) in the standard

Linux Standard Base Core Specification 3.1, Chapter 13. Base Libraries, 13.5. Interface Definitions for libc, description of strftime() function.

Accepted

LSB Bug#3774

Status

reported

[Home]