Fix truncated timepoint addition bug

[MetRonnie]

Closes #80
Closes #212

Built on #203

• Tests included
• Changelog entry included

[MetRonnie]

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

[MetRonnie]

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)

[MetRonnie]

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)

[MetRonnie]

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.

[wxtim]

Seems reasonable, code looks good and looks like it fixes the bug. Is it worth filling the gaps in the coverage whilst you're at it. I think it is.

[wxtim]

Sorry I failed to approve sooner. Please get a second reviewer or merge as you think appropriate.

[MetRonnie]

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