test_time fails in Korean Time Zone

[saschanaz]

Probably related with time zone?

$ python2 tests/runner.py test_time
WARNING:root:use EM_ALL_ENGINES=1 in the env to run against all JS engines, which is slower but provides more coverage
Test suites:
['test_core']
Running test_core: (1 tests)
test_time (test_core.default) ... (checking sanity from test runner)
INFO:root:(Emscripten: Running sanity checks)
(test did not pass in JS engine: ['/home/saschanaz/emsdk-portable/node/4.1.1_64bit/bin/node'])
ERROR

======================================================================
ERROR: test_time (test_core.default)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/saschanaz/emsdk-portable/emscripten/1.37.21/tests/test_core.py", line 2086, in test_time
    self.do_run(src, expected);
  File "/home/saschanaz/emsdk-portable/emscripten/1.37.21/tests/runner.py", line 670, in do_run
    raise e
Exception: Expected to find 'stime: -1
tzname[0] set: 1
tzname[1] set: 1
sec: 43
min: 22
hour: 3
day: 25
mon: 11
year: 102
wday: 3
yday: 358
dst: 0
off: 0
zone: GMT
timegm <-> gmtime: 1
old year still: 102
new year: 70
localtime found DST data (summer): yes
localtime found DST data (winter): yes
localtime matches daylight: yes
localtime gmtoff matches DST: yes
localtime tm_zone matches tzname (winter): yes
localtime tm_zone matches tzname (summer): yes
localtime <-> mktime: 1
mktime guesses DST (winter): 1
mktime guesses DST (summer): 1
old year still: 102
new year: 70
time: 1
difftime+: 268848637.000000
difftime-: -268848637.000000
1854 days: 365
2000 days: 366
2001 days: 365
2004 days: 366
asctime: Wed Dec 25 03:22:43 2002
winter asctime: Wed Dec 25 03:22:43 2002
summer asctime_r: Mon Jul  1 13:02:05 2002
winter asctime again: Wed Dec 25 03:22:43 2002
winter month again: 11
ctime matched: 1
clock(start): 1
clock(end): 1
' in 'stime: -1
tzname[0] set: 1
tzname[1] set: 1
sec: 43
min: 22
hour: 3
day: 25
mon: 11
year: 102
wday: 3
yday: 358
dst: 0
off: 0
zone: GMT
timegm <-> gmtime: 1
old year still: 102
new year: 70
localtime found DST data (summer): yes
localtime found DST data (winter): yes
localtime matches daylight: no
localtime gmtoff matches DST: no
localtime tm_zone matches tzname (winter): yes
localtime tm_zone matches tzname (summer): yes
localtime <-> mktime: 1
mktime guesses DST (winter): 1
mktime guesses DST (summer): 1
old year still: 102
new year: 70
time: 1
difftime+: 268848637.000000
difftime-: -268848637.000000
1854 days: 365
2000 days: 366
2001 days: 365
2004 days: 366
asctime: Wed Dec 25 03:22:43 2002
winter asctime: Wed Dec 25 03:22:43 2002
summer asctime_r: Mon Jul  1 13:02:05 2002
winter asctime again: Wed Dec 25 03:22:43 2002
winter month again: 11
ctime matched: 1
clock(start): 1
clock(end): 1
', diff:

--- expected
+++ actual
@@ -17,8 +17,8 @@
 new year: 70
 localtime found DST data (summer): yes
 localtime found DST data (winter): yes
-localtime matches daylight: yes
-localtime gmtoff matches DST: yes
+localtime matches daylight: no
+localtime gmtoff matches DST: no
 localtime tm_zone matches tzname (winter): yes
 localtime tm_zone matches tzname (summer): yes
 localtime <-> mktime: 1



----------------------------------------------------------------------
Ran 1 test in 4.236s

FAILED (errors=1)

[kripken]

Yeah, this test depends on the local time zone. I don't think we found an easy way to make it 100% deterministic and independent of the system it's running on. But you can probably ignore that failure, and skip it when running the test suite.

[saschanaz]

@kripken The problem is this also fails on Travis, but well, probably we can manually set time zone there.

[saschanaz]

BTW, which time zone is expected here?

[juj]

I think the time zone should be able to vary, not sure what this failure is about. The bots run through the test suite with Finnish time zone (UTC+3 in Summer, UTC+3 during Winter, https://www.timeanddate.com/time/zone/finland), and I don't think I've observed the bots to fail "seasonally". I wonder if the failure might be that it expects that DST should be in effect, whereas for some reason it was not when the test was run?

[hujiajie]

I'm faced with the same issue in PRC, and have opened PR #5624 to fix this. Please take a look, thanks!

[saschanaz]

This is fixed, closing.