[tz] Buggy %z behaviour in strftime

[Brian Inglis]

There may may be no response for a while, as the next joint WG14/INCITS/C (was 
PL22.11) meeting is next week, agenda is CD ballot and NB comments, and next 
meeting is in 2 months mid-April, and expected agenda is FCD and DIS.

Unless the submission is accepted and someone can get the item discussed under 
other business, it may not be on any agenda until mid-June or autumn.

One point of order is that the latest WCD was 2022-09-03 *N3054* and any DR 
should refer to that doc §7.29.3.5¶3 p408 at:

	https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf#page=427

As WG14 and INCITS/C are independent and work jointly, it may be useful to 
submit a change proposal to INCITS/C, and also to the Austin Group, perhaps with 
the help of some on the list who are or whose org is a member 
(Apple/Google/IBM/MS/Oracle?)

If you also change tzcode docs to follow your proposal and something like the 
POSIX [tm_isdst] or Linux/glibc man-pages (Calculated from /tm_isdst/.) 
dependency statements, by adding tm_gmtoff, timezone, altzone or TM_GMTOFF, and 
tzname or TM_ZONE, as appropriate, referring to the proposal, that would soon 
get an instance of the changes out to projects that distribute your docs.

Similar changes could go in a patch to the Linux man-pages project, perhaps a 
followup to Almaz post last year

https://lore.kernel.org/linux-man/CAJ0cOr-v1GDCqsU86w-rZVvejtppOAW56FxApFPnfPwRmAd47w@mail.gmail.com/t/#u

CC current maintainer Alejandro Colomar alx DOT manpages AT gmail DOT com.
That would get another instance of the proposal and changes out there on distros 
which distribute up to date kernels, glibc, and man-pages.

Others could also submit copies of the proposal to any standards bodies, and 
suitable patches referring to the proposal and making the changes, to library 
and doc projects with which they have contact.

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada


On 2023-02-10 03:42, Almaz Mingaleev via tz wrote:
> Just curious, was there any response?
> 
> On Mon, 18 Jul 2022 at 18:19, Paul Eggert <eggert at cs.ucla.edu 
> <mailto:eggert at cs.ucla.edu>> wrote:
> 
>     On 7/18/22 09:03, Paul Eggert wrote:
>      >
>      > I suppose someone should file a defect report with the C standardization
>      > committee.
> 
>     I found what I hope is the correct email address for that (it's not
>     well-advertised) and submitted the following bug report:
> 
>     ----
> 
>     Subject: strftime %z and %Z depend on more than just tm_isdst
> 
>     A recent discussion in the Time Zone Database mailing list
>     <https://mm.icann.org/pipermail/tz/2022-July/031674.html
>     <https://mm.icann.org/pipermail/tz/2022-July/031674.html>> has prompted
>     me to file this bug report against the C standard.
> 
>     Draft N2912, section 7.28.3.5 "The strftime function", pages 365-6,
>     paragraph 3 says that the %z and %Z conversion specifiers examine only
>     the tm_isdst members of the passed-in structure. However, this is not
>     how many implementations actually behave.
> 
>     Some implementations (e.g., AIX, Solaris) infer %z and %Z output from
>     tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec, and tm_isdst, and
>     therefore sometimes guess %z or %Z output incorrectly when the clock
>     moves back from one standard time to another (e.g., Iran at the end of
>     the year 1978). These implementations typically also depend on the
>     current setting of the TZ environment variable.
> 
>     Other implementations (e.g., FreeBSD, GNU/Linux) get the UT offset and
>     abbreviation from struct tm members tm_gmtoff and tm_zone that are not
>     specified by the C standard. These implementations do not have to guess
>     %z and %Z output; however, they require that the nonstandard members be
>     filled in correctly by localtime or equivalent.
> 
>     Implementations that conform to the standard's current wording cannot
>     handle anything more complicated than a time zone with just one standard
>     time offset and abbreviation, which means they cannot handle timestamps
>     for locations like Iran, Portugal, etc., that have changed their
>     standard-time offset. The C standard should not require implementations
>     to be so limited that they cannot handle common timekeeping situations.
> 
>     A simple fix for this issue is to require applications to initialize a
>     struct tm as if by localtime or equivalent, before passing the struct tm
>     to strftime. This is what applications need to do anyway, if they want
>     to be portable to real-world systems such as AIX, FreeBSD, GNU/Linux,
>     Solaris, etc.
> 
>     Proposed fix:
> 
>     1. Remove the two instances of "[tm_isdst]" in the %z and %Z entries in
>     Draft N2912, section 7.28.3.5 "The strftime function", pages 365-6,
>     paragraph 3.
> 
>     2. Add the following text to that paragraph:
> 
>     If the %z and %Z conversion specifiers are used, the broken-down time
>     structure pointed to by timeptr shall contain values generated by a
>     successful previous call to gmtime, gmtime_r, gmtime_s, localtime,
>     localtime_r, localtime_s, or mktime.