The way day/date attributes are used has changed. Recall how day/date with time attributes:
Here the day/date act like a guard over the time. Hence the time is not considered until the day/date is free.
task t1 # run on Monday @ 10:00 day monday time 10:00 | task t1 # run on Monday @ 10:00 date 05.08.2019 time 10:00 |
|---|
In ecflow 4.0 the definition below can produce unexpected runs.
...
family f1
time 10:00 # set free on Sunday
task t1
day monday # runs Monday@00:00 and Monday@10.00
In ecflow 4.0 the day/date act like a guard over any other time attribute.
Hence the time is not considered until the day is free
...
family f1
day monday
task t1
time 10:00 # runs on Monday@10.00
...
family f1
time 10:00 # set free on the sunday
task t1
day monday # runs Monday@00:00 and Monday@10.00
The behaviour in ecflow 4.0 happens because the time attribute are treated individually. Here the time 10:00, was set free on Sunday. (when time attributes are set free, they stay free, until re-queue.) ecflow 4.0 ...
family f1
day monday
task t1
time 10:00 # runs Monday an midnight and Monday at 10.00
|
|---|
...
family f1
time 10:00 # time set free on Sunday. Stays free until re-queue
task t1
day monday # runs Monday an midnight and Monday at 10.00
In ecflow 5.0, The day acts like a guard over the time.
The time is not set free, until Monday is free.
Hence this produces the expected results.
...
family t1
day monday
task t1
time 10:00 # run on Monday @ 10:00
...
family f1
time 10:00 # time set free on Sunday. Stays free until re-queue
task t1
day monday # runs Monday an midnight and Monday at 10.00
Hence in ecflow 5.0, in the following definition, the task will never run:
family f1
day monday
task t1 # t1 will never run, cant be Monday and Tuesday at the same time
day tuesday