Project

General

Profile

Bug #13591

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

Added by MSP-Greg (Greg L) about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
ruby -v:
ruby 2.5.0dev (2017-05-27 trunk 58911) [x64-mswin64_140]
[ruby-core:81347]

Description

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

See GitHub PR 1627

Updated by usa (Usaku NAKAMURA) about 3 years ago

  • Status changed from Open to Rejected

Updated by MSP-Greg (Greg L) about 3 years ago

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?

Updated by usa (Usaku NAKAMURA) about 3 years ago

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.

Updated by MSP-Greg (Greg L) about 3 years ago

  • 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...

Updated by MSP-Greg (Greg L) about 3 years ago

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.

Updated by Eregon (Benoit Daloze) about 3 years ago

  • 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.

Updated by naruse (Yui NARUSE) about 3 years ago

  • 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.

Updated by MSP-Greg (Greg L) about 3 years ago

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.

Updated by Eregon (Benoit Daloze) about 3 years ago

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).

Updated by MSP-Greg (Greg L) about 3 years ago

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...

#12

Updated by Eregon (Benoit Daloze) about 3 years ago

  • 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]

Updated by Eregon (Benoit Daloze) about 3 years ago

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.

Also available in: Atom PDF