This fix is, I think, a red herring:
------------- commit e000d8e59b037f2e7a4a6cbea754b09235071a67 (HEAD -> 8.1, origin/8.1) Author: Henrik Grubbström (Grubba) grubba@grubba.org Date: Sat Dec 23 15:12:41 2017 +0100
Runtime: Fix mktime() on platforms without gmtoff in struct tm.
For some reason the old approach was off by 3600 seconds for eg 2017-07-14T12:03:22+0000 when executed in the CET timezone.
Fixes testsuite failures on Solaris 10. -------------
The original code worked fine on Solaris 10, but only in one of two variants (at pike level).
To quote my original report:
test_eq(mktime (33, 3, 12, 14, 6, 117, 0, 0), 1500033813); test_eq(mktime ((["sec":33, "min":3, "hour":12, "mday":14, "mon":6, "year":117, "timezone":0])), 1500033813);
They should be equivalent. And they are (on other machines), but on this machine, they differ
It calls (in Pike) mktime (33, 3, 12, 14, 6, 117, 0, 0), which always works and shows the expected result.
It also calls (in Pike) mktime ((["sec":33, "min":3, "hour":12, "mday":14, "mon":6, "year":117, "timezone":0])), which returns a value that is offset by 3600.
Both mktime() invocations should be having the exact same parameters, just in a different form. So this cannot give a different result, yet it does. The codechange you propose might be fine, though it's unpleasant if DST is not exactly an hour; so the original code was more generic.
Nonetheless, I'd like to know why the original difference came from.