[tz] strftime %s

[Paul Eggert]

On 2024-01-10 11:20, Paul Eggert wrote:
> This is a tricky area, as the C standard and POSIX both require strftime 
> to look only at tm_isdst when formatting %z and %Z.

In rereading the C standard and POSIX, I see I was too hasty here. For 
strftime the standards actually use wording like the following[1]:

> Each conversion specifier is replaced by appropriate characters as described in the following list. The appropriate characters are determined using the LC_TIME category of the current locale and by the values of zero or more members of the broken-down time structure pointed to by timeptr, as specified in brackets in the description.

This wording doesn't specifically say that strftime must ignore all 
information other than the bracketed members and the LC_TIME category; 
it merely calls out information that strftime can use. In general 
strftime cannot ignore all the other information, as in general strftime 
must look at the TZ setting and the LC_CTYPE category. So the standards' 
wording (admittedly confusingly) does allow strftime to pay attention to 
information outside the bracketed list.

Also, my earlier (hasty) reading, which prohibited strftime from 
inspecting any bracketed members other than those listed, is 
incompatible with common practice and with POSIX 202x/D3. For example, 
for %z POSIX 202x/D3 lists "[tm_isdst, tm_gmtoff]" whereas C17 lists 
only "[tm_isdst]". My earlier (hasty) reading would have C17 prohibiting 
the use of any member other than tm_isdst to process %z, but this is not 
the intent of POSIX 202x/D3 and it's not how localtime implementations 
typically behave: they just consult tm_gmtoff to determine %z.

With this in mind, your proposed patch looks like a good approach. It's 
much simpler than other approaches mentioned in this thread that would 
add members to struct tm and therefore would be a major pain, or that 
would add new functions strftime_z and strftime_lz which would also 
cause significant pain.

However, your proposed patch has a glitch: in extreme cases its "mkt -= 
t->TM_GMTOFF" could suffer from integer overflow, which means the 
behavior could be undefined for cases that should simply fail, and also 
some valid inputs could mistakenly fail. To fix this glitch we can use 
timeoff rather than timegm.

I installed the attached to implement your patch's idea, but using 
timeoff rather than gmtime. Most of the patch is plumbing that makes 
timeoff visible to strftime even if timeoff is not otherwise extern. 
Please give this patch a try.

[1]: 
https://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html#tag_16_576_03
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-For-strftime-z-use-tm_gmtoff-if-available.patch
Type: text/x-patch
Size: 3789 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20240113/9ce09b28/attachment.bin>