Deal with date skew

[michielbdejong]

There are multiple date types (for balance, for interest, for exchange rate, for entry), and they are reported in different ways and don't always match. There is not one date that can be used. Also, the time-of-day component is often missing (so we pretend the mutation took place at midnight GMT but that's not accurate, we should say we know it took place some time between midnight am on the day and midnight am the next day).

[michielbdejong]

Another (often more reliable) way to identify mutations is by looking at the log order. Example:

Alice reports:

• 1 January Alice -> Bob 1 EUR
• 15 January Alice -> Bob 15 EUR
• 31 January Alice -> Bob 31 EUR

Bob reports:

• 1 January Alice -> Bob 1 EUR
• 16 January Alice -> Bob 15 EUR
• 31 January Alice -> Bob 31 EUR

They both report the same ordered list of 3 transactions for January, so we can link them based on "previous" and "next". So then you can peg a skewed transaction to the last correct one. But then what happens if every transaction is skewed? And the start and end date/time would then also not be reliable.

[michielbdejong]

heuristic: If:

• there is a matched chunk
• there is an adjacent floating departure and a floating arrival, and the amount/unit match
• the date skew is at most 1 day

Then use the earliest date and merge.

[michielbdejong]

i'll start with implementing this in the forward direction

[michielbdejong]

and maybe only if to.date is 24 hours after from.date.