Note this does not fix cylc/cylc-flow#2382, presumably that is still a bug in cylc-flow

Actually which should the behaviour be?

2019-01-15 + --01-15 = ?

1. 2019-01-15 - same point (current behaviour)
2. 2020-01-15 - next matching point (what I think it should be)

Actually which should the behaviour be?

2019-01-15 + --01-15 = ?

1. 2019-01-15 - same point (current behaviour)
2. 2020-01-15 - next matching point (what I think it should be)

I think we have to maintain the current behaviour to avoid breaking next() in Cylc workflows - see cylc/cylc-flow#5777

(Technically we could change the behaviour here and add a workaround in Cylc, but that's more effort)

Decision on 2019-01-15 + --01-15 (with greater clarity and precision):

The behaviour is to be:

2019-01-15T00:00:00 + --01-15
>>> 2019-01-15T00:00:00  # same datetime (we are exactly at midnight)

2019-01-15T00:00:01 + --01-15
>>> 2020-01-15T00:00:00  # next year 

This is because a truncated datetime should assume 0 for any unspecified time units, and 1 for any unspecified date units lower than what has been specified.

No worries, this has not been a top priority at the moment