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.