[tz] Buggy %z behaviour in strftime

[Almaz Mingaleev]

Just curious, was there any response?

On Mon, 18 Jul 2022 at 18:19, Paul Eggert <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> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20230210/68730696/attachment.html>