[tz] Direct implementation of mktime_z

[Ted Phelps]

On 28/9/22 01:22, Robert Elz via tz wrote:
> FWIW, the "indirect" implementation of mktime() (et.al.) wasn't for any
> efficiency aims - in fact, IMO, any application for which the efficiency
> of mktime() matters is probably doing something badly wrong, and the whole
> method ought to be reconsidered.

Perhaps.  I noticed that one of the problems people have reported with 
adopting the "right" time zones is that many programs assume that a day 
is exactly 86,400 seconds and such.  It's hard to argue that they 
shouldn't if it takes a significant amount of time to do it the right way.

But that ship has probably already sailed.

> Rather, I always considered it the right way for two reasons - it always
> works (regardless of what type time_t happens to be - back then that was
> even less settled than today ... dealing with unsigned time_t vs signed
> sometimes causes issues), and second, it means all the various rules
> (days/month, leap years, ....) need appear only in one place, rather than
> in two.
>
> The latter is what really swung it for me.

That's certainly a reasonable choice to make, and the reason why I 
wanted to check with the list first instead of building something that 
no one wants.

I'm not fussed either way.  If there's interest, I'll put together a 
patch series to integrate the logic into localtime.c. If you folks would 
rather not have the additional code and associated maintenance costs 
then that's entirely fine with me. I'm happy to continue maintaining a 
separate, alternate library for people who want mktime to be faster for 
whatever reason.

-Ted