[tz] Direct implementation of mktime_z

Ted Phelps phelps at pobox.com
Sat Sep 24 05:29:29 UTC 2022

On 24/9/22 04:51, Paul Eggert wrote:
> On 9/23/22 04:19, Ted Phelps via tz wrote:
>>      https://github.com/tphelps/tz64/
>> The performance improvement is substantial; on my laptop (Intel
>> i7-8550U, 4GHz) it takes about 35ns to convert a struct tm to a time_t;
>> whereas mktime_z takes about 3,300ns.
>> Which, finally, brings me to my question: is there any interest in
>> reworking tzcode's mktime to use a more efficient algorithm?
> Sure, if it's easy. Would you be willing to contribute code under the 
> current license for mktime? It's public domain. We could add your name 
> to the credits, if that would help.

I'll try to make it easy.  Yes, I have no problem contributing under the 
current license.

One important trick I've used is to embed a year/month/day/hour/minute 
value in a 64 bit integer for each leap second.  That would work out to 
8 x TZ_MAX_LEAPS = 400 extra bytes in struct state.  Is that likely to 
be a problem?

> Although I don't want tzcode to assume 64-bit signed time_t, I assume 
> it wouldn't be hard to relax that assumption.

Agreed.  It's easy to do the math in 64 bits and then return an error if 
the result doesn't fit into 32.  It's rather harder to do the math in 32 
bits since there are so many opportunities to overflow, but I see that 
there's already an int_fast64_t type in localtime.c so I guess 64-bit 
math is acceptable?


More information about the tz mailing list