[CI] TypeError: in new, expected Union{Nothing, DateTime}, got a value of type Int64

[arnaudh]

CI test consistently fails, likely due to TimeZones v1.6 which changed the representation of FixedTimeZone.

Last night's job: https://github.com/invenia/JLSO.jl/runs/3921890556?check_suite_focus=true

[warn | JLSO]: TypeError: in new, expected Union{Nothing, DateTime}, got a value of type Int64
v3_julia_serialize_gzip_fastest.jlso: Test Failed at /home/runner/work/JLSO.jl/JLSO.jl/test/backwards_compat.jl:67
  Expression: jlso_data == datas
   Evaluated: Dict{Symbol, Any}(:ZonedDateTime => UInt8[0x1f, 0x8b, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0x13  …  0xfe, 0x5f, 0x68, 0x59, 0x16, 0x12, 0xab, 0x33, 0x00, 0x00], :DataFrame => 5×4 DataFrame
 Row │ a      b         c       d
     │ Int64  Float64   String  Bool
─────┼────────────────────────────────
   1 │     1  0.867244  a        true
   2 │     2  0.711437  b        true
   3 │     3  0.512452  c       false
   4 │     4  0.863122  d       false
   5 │     5  0.907903  e        true, :Vector => [0.867244, 0.711437, 0.512452, 0.863122, 0.907903], :DateTime => DateTime("2018-01-28T00:00:00"), :String => "Hello World!", :Matrix => [0.400348 0.892196 0.848164; 0.0183529 0.755449 0.397538; 0.870458 0.0441878 0.170899], :Distribution => Normal{Float64}(μ=50.2, σ=4.3)) == Dict{Symbol, Any}(:ZonedDateTime => ZonedDateTime(2018, 1, 28, tz"America/Chicago"), :DataFrame => 5×4 DataFrame
 Row │ a      b         c       d
     │ Int64  Float64   String  Bool
─────┼────────────────────────────────
   1 │     1  0.867244  a        true
   2 │     2  0.711437  b        true
   3 │     3  0.512452  c       false
   4 │     4  0.863122  d       false
   5 │     5  0.907903  e        true, :Vector => [0.867244, 0.711437, 0.512452, 0.863122, 0.907903], :DateTime => DateTime("2018-01-28T00:00:00"), :String => "Hello World!", :Matrix => [0.400348 0.892196 0.848164; 0.0183529 0.755449 0.397538; 0.870458 0.0441878 0.170899], :Distribution => Normal{Float64}(μ=50.2, σ=4.3))
Stacktrace:
 [1] macro expansion
   @ ~/work/JLSO.jl/JLSO.jl/test/backwards_compat.jl:67 [inlined]
 [2] macro expansion
   @ /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Test/src/Test.jl:1226 [inlined]
 [3] macro expansion
   @ ~/work/JLSO.jl/JLSO.jl/test/backwards_compat.jl:61 [inlined]
 [4] macro expansion
   @ /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Test/src/Test.jl:1151 [inlined]
 [5] macro expansion
   @ ~/work/JLSO.jl/JLSO.jl/test/backwards_compat.jl:60 [inlined]
 [6] macro expansion
   @ /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Test/src/Test.jl:1151 [inlined]
 [7] top-level scope
   @ ~/work/JLSO.jl/JLSO.jl/test/backwards_compat.jl:2

Potential fix: #114

[oxinabox]

#114 won't fix really.
But it will make it easier to not load using the wrong version of TimeZones.

But even without that you can bound TimeZones.jl to less then 1.6
e.g ~1.1,~1.2,~1.3,~1.4,~1.5, in compat.
Until you can regenerate the data to use new format.
(Ideally, if you plan to keep it for a long time, using some other format that is implementation agnostic like Arrow or CSV)

[rofinn]

Yeah, I think for this package we should condition the tests based on the TimeZones version and then update the test files in the future. For other packages, you'll just need to regenerate the .jlso files. I do kind of wonder if we could do some kind of introspection to generate a compat struct when loading types that have changed...? This also happened for a breaking Distributions.jl release about 1 yr ago. We don't seem to hit it that frequently, but it's annoying when we do.