[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