datetime_test fails in 2019-11

[bmwiedemann]

Environment

• Elixir & Erlang/OTP versions (elixir --version): elixir master = 22b8238 ; OTP-21.1.4
• Operating system: openSUSE Tumbleweed 20190124

Current behavior

similar to #8688
one test fails after 2019-11-01 but passes 2019-10-26

  1) doctest DateTime.now/2 (27) (DateTimeTest)
     test/elixir/calendar/datetime_test.exs:7
     ** (FunctionClauseError) no function clause matching in FakeTimeZoneDatabase.time_zone_periods_from_utc/2
     
     The following arguments were given to FakeTimeZoneDatabase.time_zone_periods_from_utc/2:
         
         # 1
         "Europe/Copenhagen"
         
         # 2
         {{2019, 11, 1}, {0, 1, 32}}
     
     stacktrace:
       test/elixir/calendar/fakes.exs:56: FakeTimeZoneDatabase.time_zone_periods_from_utc/2
       (elixir) lib/calendar/datetime.ex:443: DateTime.shift_zone_for_iso_days_utc/5
       (for doctest at) lib/calendar/datetime.ex:483: (test)

Might this be related to the EU intentions to give up DST?

Expected behavior

Tests should keep working until at least 2037-01

[josevalim]

We use a fake time zone database, not an actual one, where ranges are hard coded. So as long as you modify the fake database, you should be good to go: https://github.com/elixir-lang/elixir/blob/master/lib/elixir/test/elixir/calendar/fakes.exs

[bmwiedemann]

Was this meant to be closed? If so, a link to the fix would be nice...

[josevalim]

Hi @bmwiedemann!

There is no fix because this is not an issue per se. We don't use an actual timezone database and instead we use a fake one. So if you want to change the test, you also have to change the fake timezone database.

However, maybe there is another issue that led you to open this one? Maybe that's what we should focus on?

[bmwiedemann]

The issue is that today's elixir will stop building in 11 months. It is an issue that is just not very visible right now, so most people are happy with the current state.
Such time-bombs are not nice to distributions like our openSUSE who want to ship software and keep it working for a longer time.

[bmwiedemann]

Also all the background and reasoning from #8688 applies. I just did not catch it there because the test probably was not part of elixir-1.7.4

[josevalim]

@bmwiedemann perfect. That's the context I was missing. Can you please link to the part that will fail to build in 11 months so we can check it?

[josevalim]

Oh, nevermind. I can infer that from the failed test. DateTime.now is using a timezone database and that will fail eventually. Fix coming out soon.

[bmwiedemann]

likely from https://github.com/elixir-lang/elixir/blob/master/lib/elixir/test/elixir/calendar/fakes.exs#L70 not covering anything after 2019-10-28

[josevalim]

@bmwiedemann btw, can you show the commands you are using to make the build "run in the future"? I wonder if we should add that as an entry in our travis matrix.

[bmwiedemann]

In openSUSE I use kvm's clock fiddling with
osc build --vm-type=kvm --build-opt=--vm-custom-opt="-rtc base=2019-11-01T01:01:01"

but in travis you might have an easier time with libfaketime

faketime -f '+10y' date
Mon Jan 22 10:11:02 CET 2029

could maybe even integrated into the 2nd build of #8701 - if that includes running tests

[bmwiedemann]

Tested with latest master and all tests pass now (and in 2034).
Might still break later when the EU figures out how to stop doing DST changes, though, because we regularly update the timezone package to sync with what politicians around the world decided.

[eksperimental]

@bmwiedemann faketime doesn't work, we are getting around 50 tests not passing.
Dou you know if using the hwclock --set will work? Or you can see us having an issue?
I can see if Travis would let me do that

[bmwiedemann]

It seems, faketime indeed has its problems.
hwclock is probably not what you want, because that would change the hardware clock, when you only want to change the Linux system clock with
date --set @2100000000
It requires root permissions and might not work in a container.