[tz] proposed changes for Win32 and a improved mktime() algorithm

Paul Eggert eggert at cs.ucla.edu
Wed May 10 04:02:01 UTC 2017


Robert Elz wrote:
>   | 2.       Adding a faster (and more efficient) algorithm for mktime().
>   |	     Instead of the binary search another approach is used,
>
> I think that kind of thing is fine for a system's implementation of
> mktime(), but I don't think it is best for the reference implementation.

Normally I'd agree. However, there is an alternative that would let us do both. 
We could use the glibc implementation of mktime. Like tzcode's mktime, it's 
independent of the rest of the implementation and is quite portable. And like 
the recently-proposed code, it's waay faster than binary search. A major 
advantage is that glibc is well-tested on many platforms to handle corner cases 
such as the ones that you mention. An advantage over the proposed code is that 
its copyright status is clear.

The only downside that I can see is that it's LGPLed, which some of our 
downstream users might not like. If that's a showstopper, perhaps we could make 
the glibc version available as an option, so that LGPL-averse users can stick 
with what we've got. I'd rather not have to debug a whole new set of code for 
what should be a solved problem, though.

(Disclaimer: I wrote both the tzcode mktime and the glibc mktime.)


> Assuming that this is the reason for ...
>
> -	static const char	wday_name[][3] = {
> +	static const char	wday_name[][4] = {
>
> Then IMO that system is just broken, it has always been legal to provide
> a string where the non-null chars exactly fill the space provided, in
> which case the terminating \0 is simply omitted from the initialisation.
>
> If some system has broken that, it should be made to suffer, we should
> not be working around it.

All true. Still, the C code is a little clearer when written with 
null-terminated strings, so I'm mildly inclined to change the 3 to a 4 anyway.


I agree with your other comments. I'll follow up separately to Kees.


More information about the tz mailing list