[tz] proposed changes for Win32 and a improved mktime() algorithm
Kees.Dekker at infor.com
Mon May 29 12:36:21 UTC 2017
>> Also, that's why we have improved mkime (with the time_succesive() code), as the current approach
>> is pretty inefficient.
>If this change can be separated out and made portable and reliable in
>the presence of integer overflow and unsigned time_t and so forth, it
>should be OK. As I recall the proposed change is a long way from that,
>though. From my point of view the simplest thing to do would be change
>the code to use GNU mktime, as a build-time option (default off) for
>people who want speed and don't mind the GPL.
Attached a new patch, only covering the time_succesive() part. Inconsistencies in using spaces or tabs in idents (e.g. in time(), init_ttinfo())
are ignored. I'm using the same (inconsistent) mix of idents. These were (partially) fixed in our own code, but omitted in the patch.
The code is provided as is. Free to use, no restrictions, under same conditions as IANA provides its software. You are free to adopt, change
the code, including rewrite, removal of comments (and the name of my colleague).
The core part of time_succesive() is explained in the comments in time_successive():
/* As an initial guess for the correct time_t value,
take the utc value of 00:00:00 at the 3rd day of the specified month and year.
When calculating that value back to a struct tm,
at least the year and the month will be correct.
The patch has been created on top of latest tz changes (as of today). As said before: the ambiguity for DST changes is different,
compared to the original/IANA's implementation.
The code does not (yet) check for integer overflows. But hopefully, the patch will already give you an
impression about its mindset. Just compile with -DUSE_TIME_SUCCESSIVE to make the new code active.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7326 bytes
More information about the tz