[tz] [PROPOSED 2/2] strftime: conform better to POSIX+

[Paul Eggert]

On 8/10/20 12:58 AM, Robert Elz wrote:

> The only comment I'd make about that, and this is just style, is that
> instead of ...
> 
>    | +	timeout(stdout, format ? format : "+%+", tmp);
> 
> we simply init format before (actually during) the arg processing

Good suggestion; done via the attached proposed patch ("Subject:" line 
misspelling and all :-).

> 
>    | General-purpose  routines don't always have the luxury of knowing that
>    | format[-1] is available.
> 
> No, they don't, but someone designing a general purpose routine to
> use strftime (or for that matter, anything) should design it around
> the characteristics of strftime (or whatever).

It's too late for that. Many APIs have already been designed. Plus, this really 
is an botch/awkwardness in the strftime API, and it'd be a shame for it to force 
similar botches/awkwardnesses in new APIs.

> ps: to get the ERANGE accepted by posix, it needs to be the standard
> (or at least common) behaviour first, POSIX specifies what the standard
> is, it doesn't (usually anyway) invent it 

The POSIX draft is already doing that to strftime, by requiring EOVERFLOW where 
many implementations don't do EOVERFLOW, and similarly for EINVAL for the odd 
implementations that don't support negative time_t. As long as it's specifying 
errno de novo anyway, it might as well fix this longtime botch.

I have a similar beef with mktime, by the way: there's not a well-designed way 
to distinguish success from failure. But that's trickier since the botch has 
been in POSIX for a while. All this strftime errno stuff is new.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-date-simplify-format-compuation.patch
Type: text/x-patch
Size: 1958 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20200811/1166e31e/attachment.bin>