Bug #13591: spec/rubyspec/core/time/zone_spec - Windows does not support ENV['TZ']

• Status: Closed
• Assignee: Eregon (Benoit Daloze)
• Target version: -
• ruby -v: ruby 2.5.0dev (2017-05-27 trunk 58911) [x64-mswin64_140]
• Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN

[MSP-Greg (Greg L)]

Windows does not support ENV['TZ'], so it should be removed from rspec tests.

See GitHub PR 1627

[usa (Usaku NAKAMURA)]

• Status changed from Open to Rejected

MSVCRT uses TZ.
See https://msdn.microsoft.com/en-us/library/w4ddyt9h.aspx

[MSP-Greg (Greg L)]

Using a MinGW build, ENV['TZ'] seemed to have no affect on Time, and time zone spec tests failed.

I had previously been looking at 'Microsoft Time Zone Index Values'. Time#zone returns a value from the list, but setting ENV['TZ'] to another value did not seem to have the expected result.

Given that spec tests are not currently included in appveyor, do you know if the test 'defaults to UTC when bad zones given' passes on a mswin64 build?

[usa (Usaku NAKAMURA)]

MSP-Greg (Greg L) wrote:

Given that spec tests are not currently included in appveyor, do you know if the test 'defaults to UTC when bad zones given' passes on a mswin64 build?

You can see the results on RubyCI.
vc12-x64 (known as mswinci) is a mswin64 CI.
Its report of trunk includes the result of Spec.

[MSP-Greg (Greg L)]

• ruby -v changed from ruby 2.5.0dev (2017-05-18 trunk 58780) [x64-mingw32] to ruby 2.5.0dev (2017-05-27 trunk 58911) [x64-mswin64_140]

Having now built with mswin-build, this test still fails. Also, I'm seeing some of the same issues in test-all (test-enum callcc segv, etc).

Please try and run the spec tests (or this specific test) from a command prompt. Something is amiss if I'm getting different results...

[nobu (Nobuyoshi Nakada)]

I haven't seen such failure on AppVeyor yet.
https://ci.appveyor.com/project/nobu/ruby/build/1.0.119

[MSP-Greg (Greg L)]

Nobu,

I'll have a look at your code, see if I can determine whats going on. Believe me, I did a couple of builds, and it kept failing...

Thanks.

[Eregon (Benoit Daloze)]

• Assignee set to Eregon (Benoit Daloze)

FWIW the patch looks OK to me, I think we should merge it.

This might be a difference between the different configuration of Windows builds.
Testing for invalid timezones is rather difficult,
some platforms behave differently, and this test had to be refined a couple times to work on all Linux CIs.

MSP-Greg (Greg L) wrote:

I'll have a look at your code, see if I can determine whats going on. Believe me, I did a couple of builds, and it kept failing...

Could you just post a failing stacktrace here when running the test in isolation?
You can do so with $ make test-rubyspec MSPECOPT="-e bad spec/rubyspec/core/time/zone_spec.rb"
or $ spec/mspec/bin/mspec -e bad spec/rubyspec/core/time/zone_spec.rb
if the built ruby is on $PATH.

[naruse (Yui NARUSE)]

• Status changed from Rejected to Feedback

Once I reproduced the behavior, but after some maintenance of my mingw environment, it doesn't appear.

Anyway at this time, it's considered as a bug of ruby or spec or mingw or something.
Just removing spec sounds not appropriate.

[MSP-Greg (Greg L)]

Sorry for the delay, I'm at -0500 (Central US), and I seem to have lost a video card this morning.

Anyway, error is identical to mingw mspec. Below is the full rubyspec results from nmake (I believe the 2nd failure is intermittent):

1)
Time#zone defaults to UTC when bad zones given FAILED
Expected 3600
 to equal 0

E:/build/mswin-build/ruby/spec/rubyspec/core/time/zone_spec.rb:68:in `block (4 levels) in <top (required)>'
E:/build/mswin-build/ruby/spec/rubyspec/core/time/zone_spec.rb:67:in `block (3 levels) in <top (required)>'
E:/build/mswin-build/ruby/spec/rubyspec/core/time/zone_spec.rb:3:in `<top (required)>'

2)
C-API Thread function rb_thread_call_without_gvl runs a C function with the global lock unlocked FAILED
Expected nil not to be nil
E:/build/mswin-build/ruby/spec/rubyspec/optional/capi/thread_spec.rb:114:in `block (3 levels) in <top (required)>'
E:/build/mswin-build/ruby/spec/rubyspec/optional/capi/thread_spec.rb:16:in `<top (required)>'

Finished in 214.546800 seconds

3568 files, 25779 examples, 202018 expectations, 2 failures, 0 errors, 0 tagged
NMAKE : fatal error U1077: '.\ruby.exe' : return code '0x1'

I've got recent mswin and mingw builds, and did some irb exploring. On windows, ENV['TZ'] seems like a read-only setting.

My mingw/MSYS2 env is up to date, and I run as much of my building from the command prompt as possible, with only what is required in PATH. As to MinGW, I've built several OpenSSL packages (which pass all OpenSSL and Ruby OpenSSL tests), and a GDBM package. The doc site is generated from recent mingw builds, and I've got curses, eventmachine w/SSL, libxml, nokogiri, rdiscount, redcarpet, RedCloth, and Thin gem extensions installed.

I'm building mswin with VS2017, and I'm using Win7. I may have OpenSSL-Win 1.1.0f configured wrong, as I've got an issue in test-all that stops it. I hope to get mswin test-all completing soon. Previous builds seemed to show a segv issue that also occurred in MinGW builds with test_enum.rb / TestEnumerable#test_callcc.

[Eregon (Benoit Daloze)]

Interesting, an offset of 3600 means 1 hour so UTC+1, like current TZ=Europe/London summer time.

Does anyone know what could go wrong?

I am thinking part of it might be that C functions related to time
might behave slightly differently between OS and
the result might also depend on the system time zone and settings
(if the system time zone is UTC then we cannot test the difference between local zone and UTC zone).

[MSP-Greg (Greg L)]

Usaku,

You are correct. Linked from the page you mentioned is _tzset. This (sort of) doc's what ENV['TZ'] can be set to.

From my testing, the strings can be anything. I called the following with several strings.

puts "TZ          DST    SST"
def tz_test(s)
  dst = [2017, 6, 1, 12, 0]  # daylight - June
  sst = [2017, 1, 1, 12, 0]  # standard - January
  ENV['TZ'] = s
  puts "#{s.ljust(10)} #{(Time.new(*dst).utc_offset/3600).to_s.rjust(4)}   #{(Time.new(*sst).utc_offset/3600).to_s.rjust(4)}"
end

output below.

TZ          DST    SST
hello-foo     1      0
hello+foo     1      0
1,2           0      0
Sun,Fri,2     1      0
12            0      0
-1aaa         1      0

aaa+8        -8     -8
AAA+8        -8     -8
aaa+8bbb     -7     -8
AAAA+8BBBB    1      0

aaa-8         8      8
AAA-8         8      8
aaa-8bbb      9      8
AAAA-8BBBB    1      0

A classic case of a function that assumes you have validated the input, and, if not, be prepared for anything. My opinion, Ruby mingw and mswin builds are fine, the _tzset function is expecting validation that ruby can't or shouldn't do. There's a gem for that...

[Eregon (Benoit Daloze)]

• Status changed from Feedback to Closed

Applied in changeset trunk|r59113.

---

Adapt Time#zone spec to deal with differences of TZ validation on Windows

• [Bug #13591] [ruby-core:81347]

[Eregon (Benoit Daloze)]

Fixed in r59113.
I split the spec to only include cases that seem to work on Windows according Greg's tests.
This test is inherently dependent on the OS parsing function for TZ, so we need to deal with those differences.