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