|ruby -v:||ruby 2.0.0dev (2012-11-04 trunk 37467) [i386-mingw32]||Backport:|
I'm currently travelling and am in UTC-5. I get the following
make test-all failure on Win7 32bit with mingw-w64 gcc 4.7.2. It appears that trunk@37467 is not handling daylight savings time correctly.
I'm not going to have time to try to repro on my Arch system, but can anyone else in UTC-5 (or other DST observing region) repro on either a Win7 or Linux system?
[ 3509/11467] TestFile#test_utime = 0.00 s
expected but was
Finished tests in 641.449135s, 17.8767 tests/s, 4150.9932 assertions/s.
11467 tests, 2662651 assertions, 1 failures, 0 errors, 83 skips
ruby -v: ruby 2.0.0dev (2012-11-04 trunk 37467) [i386-mingw32]
#1 Updated by Jon Forums almost 3 years ago
Appears to be a trunk regression as
TestFile#test_utime passes on ruby_1_9_3@37334
C:\Jenkins\workspace\ruby-1_9_3-svn>ruby -v test\ruby\test_file.rb
ruby 1.9.3p305 (2012-10-26 revision 37334) [i386-mingw32]
Finished tests in 1.154402s, 27.7200 tests/s, 127.3387 assertions/s.
#3 Updated by Jon Forums almost 3 years ago
This is the only test-all fail I have when building trunk on Win7 with mingw-w64 gcc 4.7.2.
This fail does not show up at http://ci.rubyinstaller.org/ because the current build slaves reside in an area that doesn't participate in the daylight savings time circus.
#8 Updated by Jon Forums almost 3 years ago
This still fails as of r38131 on my Win7 32bit system. Given Shirosaki-san's comment, what's preventing this from being quickly fixed on trunk?
Since this bug is not made visible by the rubyinstaller CI (build slave location) I will manually run any tests or builds you need in order to validate the fix. Let me know what you need.
#9 Updated by Jon Forums almost 3 years ago
Status? Is this planned to be fixed for 2.0.0?
This is the only failure I get when building trunk (
make test-all and
make test) with mingw-w64 4.7.2 32bit on Win7.
As stated previously, you don't see this failure at http://ci.rubyinstaller.org/ because Luis' build slaves are located in an uneffected timezone.
#10 Updated by Heesob Park over 2 years ago
This daylight savings time bug is described at
The workaround is using the Windows API call instead of using the C library call.
#11 Updated by Jon Forums over 2 years ago
Nobu-san: why was r37337 required and
rb_w32_fstati64 no longer correct?
Heesob: good read. After reverting r37337 as per Hiroshi's comment, I get 0 fails on trunk@38966 (Win7 32bit + mingw-w64 4.7.2) because
rb_w32_fstati64 (win32/win32.c:4474) rather than
_fstati64 which causes mingw-w64 to use msvcrt's
Given the info you linked, do you think the current
rb_w32_fstati64 is a valid workaround? Does reverting r37337 also work for you on Win8?
#14 Updated by Nobuyoshi Nakada over 2 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100