Xenofarm machine: motoko.roxen.com (maybe others too) Git pike 8.1
Case in point: In the testsuite I created two entries:
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 because of this code segment in src/builtin_functions.c (code shortened for readability, irrelevant parts omitted): ------------------------------------------ PMOD_EXPORT void f_mktime (INT32 args) { if(args == 1) { push_static_text("sec"); push_static_text("min"); push_static_text("hour"); push_static_text("mday"); push_static_text("mon"); push_static_text("year"); push_static_text("isdst"); push_static_text("timezone"); f_aggregate(8); f_rows(2); Pike_sp--; dmalloc_touch_svalue(Pike_sp); push_array_items(Pike_sp->u.array); args=8; }
get_all_args("mktime",args, "%i%i%i%i%i%i.%i%i", &sec, &min, &hour, &mday, &mon, &year, &isdst, &tz);
if((args > 7) && (SUBTYPEOF(Pike_sp[7-args]) == NUMBER_NUMBER)) { ------------------------------------------
It appears that when mktime() is called using 8 direct arguments, it works fine and (SUBTYPEOF(Pike_sp[7-args]) == NUMBER_NUMBER evaluates to true.
However, if mktime() is called using a mapping as sole argument, it works fine on most machines, but on motoko/SunOS 5.1 then (SUBTYPEOF(Pike_sp[7-args]) == NUMBER_NUMBER evaluates to false?
Any clues? I want to avoid debugging this through successive approximation and xenofarm.
NUMBER_NUMBER seems to be defined to 0, BTW.
If someone can offer temporary access to a SunOS system to me, I'd be willing to debug it.
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.
Stephen R. van den Berg wrote:
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
As it turns out, they are not equivalent. The second one, with the mapping as parameter, implicitly includes an isdst == -1.
I fixed the testsuite, and fixed the code in Val.Timestamp and reinstated the original rewrites of mktime().
pike-devel@lists.lysator.liu.se
-
Stephen R. van den Berg