floraison / et-orbi

Time zones for fugit and rufus-scheduler. Urbi et Orbi.
MIT License
24 stars 11 forks source link

Master tests broken locally #4

Closed chrisarcand closed 6 years ago

chrisarcand commented 6 years ago

Ruby version: 2.4.1 Bundler version: 1.15.4 macOS Sierra 10.12.6

When trying to run the tests locally, the following failures occur:

Failures:

  1) EtOrbi.make_time turns a Date instance into an EoTime instance
     Failure/Error:
       fail ArgumentError.new(
         "cannot determine timezone from #{zone.inspect}" +
         "\n#{render_nozone_time(s)}" +
         "\n#{self.class.platform_info.sub(',debian:', ",\ndebian:")}" +
         "\nTry setting `ENV['TZ'] = 'Continent/City'` in your script " +
         "(see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)" +
         (defined?(TZInfo::Data) ? '' : "\nand adding gem 'tzinfo-data'")
       ) unless @zone

     ArgumentError:
       cannot determine timezone from "CDT"
       (secs:1477976400.0,utc~:"0046-11-01 05:00:00.0",ltz~:"LMT")
       (etz:nil,tnz:"CDT",tzid:nil,rv:"2.4.1",rp:"x86_64-darwin16",eov:"1.0.6",rorv:nil,astz:nil,
       debian:nil,centos:nil,osx:"America/Chicago")
       Try setting `ENV['TZ'] = 'Continent/City'` in your script (see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)
       and adding gem 'tzinfo-data'
     # ./lib/et-orbi.rb:244:in `initialize'
     # ./lib/et-orbi.rb:96:in `new'
     # ./lib/et-orbi.rb:96:in `make_from_time'
     # ./lib/et-orbi.rb:101:in `make_from_date'
     # ./lib/et-orbi.rb:75:in `make_time'
     # ./spec/module_spec.rb:491:in `block (5 levels) in <top (required)>'
     # ./spec/spec_helper.rb:22:in `in_zone'
     # ./spec/module_spec.rb:485:in `block (4 levels) in <top (required)>'

  2) EtOrbi.make_time turns a String into an EoTime instance
     Failure/Error: else expect(eot).to eq(exp)

       expected: #<EtOrbi::EoTime:0x007f97e6387770 @seconds=1478021409.0, @zone=#<TZInfo::TimezoneProxy: America/Bahia_Banderas>, @time=nil>
            got: #<EtOrbi::EoTime:0x007f97e71771c8 @seconds=1478025009.0, @zone=#<TZInfo::TimezoneProxy: America/Bahia_Banderas>, @time=nil>

       (compared using ==)

       Diff:
       @@ -1,5 +1,5 @@
       -#<EtOrbi::EoTime:0x007f97e6387770
       - @seconds=1478021409.0,
       +#<EtOrbi::EoTime:0x007f97e71771c8
       + @seconds=1478025009.0,
         @time=nil,
         @zone=#<TZInfo::TimezoneProxy: America/Bahia_Banderas>>

     # ./spec/module_spec.rb:502:in `block (4 levels) in <top (required)>'

  3) EtOrbi::EoTime#monthdays returns the appropriate "0#2"-like string
     Failure/Error: expect(mds(local(1970, 1, 1))).to eq(%w[ 4#1 4#-5 ])

       expected: ["4#1", "4#-5"]
            got: ["3#5", "3#-1"]

       (compared using ==)
     # ./spec/time_spec.rb:266:in `block (3 levels) in <top (required)>'

Finished in 0.09694 seconds (files took 0.86364 seconds to load)
73 examples, 3 failures

Failed examples:

rspec ./spec/module_spec.rb[1:8:6] # EtOrbi.make_time turns a Date instance into an EoTime instance
rspec ./spec/module_spec.rb[1:8:7] # EtOrbi.make_time turns a String into an EoTime instance
rspec ./spec/time_spec.rb:264 # EtOrbi::EoTime#monthdays returns the appropriate "0#2"-like string

This is from running bundle exec rspec, which I found is the expected way to run tests from the latest CI run, which is indeed passing. I'm on the same SHA as that run, too (ff967e82f5612b01f5db05d46c2e144bddf937b0).

I would assume this is probably a Mac issue.

carbonin commented 6 years ago

This seems to be okay on the following version + OS combination:

ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux] Bundler version 1.15.4 Fedora release 25 (Twenty Five)

imtayadeway commented 6 years ago

I'm getting this failure with:

Ruby 2.4.2 Bundler 1.16.0.pre.2 Linux 4.9.0-3-amd64 Debian 4.9.30-2+deb9u3 (2017-08-06)

Failures:

  1) EtOrbi::EoTime#monthdays returns the appropriate "0#2"-like string
     Failure/Error: expect(mds(local(1970, 1, 1))).to eq(%w[ 4#1 4#-5 ])

       expected: ["4#1", "4#-5"]
            got: ["3#5", "3#-1"]

       (compared using ==)
     # ./spec/time_spec.rb:266:in `block (3 levels) in <top (required)>'

Finished in 0.04315 seconds (files took 0.35369 seconds to load)
73 examples, 1 failure

Failed examples:

rspec ./spec/time_spec.rb:264 # EtOrbi::EoTime#monthdays returns the appropriate "0#2"-like string
jmettraux commented 6 years ago

@imtayadeway

Hello,

thanks for reporting. Could you please open a separate issue for the error you're seeing? Could you please indicate in there the timezone for your system (ENV['TZ'] and, more simply, timezone as set in Debian system).

Thanks in advance!

jmettraux commented 6 years ago

@chrisarcand

Hello,

thanks for reporting. Does following "Try setting ENV['TZ'] = 'Continent/City' in your script (see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) and adding gem 'tzinfo-data'" and setting export TZ='america/chicago' before running bundle exec rspec prevents one, two or all of the spec errors you're seeing?

Thanks in advance!

jmettraux commented 6 years ago

@carbonin

Hello,

could you please pull the latest https://github.com/floraison/et-orbi/commit/67389818c2b67dc066912cc78445d542ba06625e , run make info and paste the result here?

Thanks in advance!

jmettraux commented 6 years ago

Hello, I did some work to adapt to latest Travis platform, gh-5. Does that reduce the failures on your sides?

chrisarcand commented 6 years ago

@jmettraux Nope, I pulled the latest changes you made and get the same errors.

Here's the information you seem to have added as output at the top of the tests, if you need it:

--------------------------------------------------------------------------------
Darwin carcand-OSX.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64
2.4.2 x86_64-darwin16
(secs:1507039249.3564181,utc~:"0047-10-03 14:00:49.3564181327819824",ltz~:"LMT")
(etz:nil,tnz:"CDT",tzid:nil,rv:"2.4.2",rp:"x86_64-darwin16",eov:"1.0.6",rorv:nil,astz:nil,debian:nil,centos:nil,osx:"America/Chicago")
--------------------------------------------------------------------------------
jmettraux commented 6 years ago

OK, switched my Macbook to "America/Chicago" and seeing the same failures. Fixing...

jmettraux commented 6 years ago

Hello, I think I got it fixed. Could you please confirm? Thanks in advance.

chrisarcand commented 6 years ago

Confirmed, everything's green for me now. Thanks!