Daylight savings bug causes scheduler to terminate when time is set backwards

[adz]

We found our jobs not running, and it turned out our Quantum based scheduler had terminated.

Our jobs are configured with timezone: "Australia/Adelaide", and Adelaide had daylight savings move the clock backwards one hour yesterday, resulting in ambiguous time:

<Ambiguous(#DateTime<2019-04-07 02:00:06.340067+10:30 ACDT Australia/Adelaide> ~ #DateTime<2019-04-07 01:00:06.340067+09:30 ACST Australia/Adelaide>)

Note this is different from #321 where a time does not exist due to moving forward!

This fails to convert to UTC resulting in an error and eventual termination:

** (FunctionClauseError) no function clause matching in DateTime.to_naive/1
    (elixir) lib/calendar/datetime.ex:301: DateTime.to_naive(#<Ambiguous(#DateTime<2019-04-07 02:00:06.340067+10:30 ACDT Australia/Adelaide> ~ #DateTime<2019-04-07 01:00:06.340067+09:30 ACST Australia/Adelaide>)>)
    (quantum) lib/quantum/execution_broadcaster.ex:313: Quantum.ExecutionBroadcaster.get_next_execution_time/2
    (quantum) lib/quantum/execution_broadcaster.ex:284: Quantum.ExecutionBroadcaster.add_job_to_state/2
    (elixir) lib/enum.ex:1925: Enum."-reduce/3-lists^foldl/2-0-"/3
    (quantum) lib/quantum/execution_broadcaster.ex:132: Quantum.ExecutionBroadcaster.handle_events/3
    (gen_stage) lib/gen_stage.ex:2329: GenStage.consumer_dispatch/6
    (gen_stage) lib/gen_stage.ex:2502: GenStage.take_pc_events/3
    (stdlib) gen_server.erl:637: :gen_server.try_dispatch/4
    (stdlib) gen_server.erl:711: :gen_server.handle_msg/6
    (stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3

I reproduced this by setting my system clock to 1:59am 7th April 2019 and running our app with jobs that start in less than an hour.

We're going to use UTC in our scheduler to work around.

[tlux]

I got the same issue (scheduler terminated) when the time switched from daylight savings time last Sunday (Berlin time zone), so no jobs were running on Monday. I'm on the latest version of quantum (2.3.4). Any progress on that or ideas how to solve the issue?

[maennchen]

This problem still exists /with a different error though): https://github.com/quantum-elixir/quantum-core/blob/master/lib/quantum/date_library.ex#L19

What would be the expected result?

1. Error that doesn't crash quantum but just skips until we reach a "normal" date
2. Only for the first of the two ambiguous ones
3. Only for the second of the two ambiguous ones
4. DateTime are never converted to NaiveDateTime and therefore the question never arises (needs a huge update in crontab)

They also come with different advantages / drawbacks:

If one schedules a task that runs once a day and falls into a date time shift, the task is either executed twice (for option 4), never (for option 1) or once (for options 2 & 3).

If one schedule s a task that runs every minute, the task is either not executed (for option 1), every minute of the first hour (for option 2), every minute of the second hour (for option 3) or every minute (for option 4).

A similar problem arises with gaps, if I schedule a task to run daily at the time of a gap, it would not be executed that day.

I personally think option 4 is correct. The is however a huge change since crontab has to be modified to work with DateTime instead of NaiveDateTime.