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