Support datetime interval extended type and arithmetic

[DifferentialOrange]

msgpack: support datetime interval extended type

Tarantool supports datetime interval type since version 2.10.0 [1]. This patch introduced the support of Tarantool interval type in msgpack decoders and encoders.

Tarantool datetime interval objects are decoded to tarantool.Interval type. tarantool.Interval may be encoded to Tarantool interval objects.

You can create tarantool.Interval objects either from msgpack data or by using the same API as in Tarantool:

di = tarantool.Interval(year=-1, month=2, day=3,
                        hour=4, minute=-5, sec=6,
                        nsec=308543321,
                        adjust=tarantool.IntervalAdjust.NONE)

Its attributes (same as in init API) are exposed, so you can use them if needed.

datetime, numpy and pandas tools doesn't seem to be sufficient to cover all adjust cases supported by Tarantool.

This patch does not yet introduce the support of datetime interval arithmetic.

1. Introduce TIMESTAMP type to Tarantool tarantool#5941

Part of #229

msgpack: support datetime interval arithmetic

Support datetime and interval arithmetic with the same rules as in Tarantool [1].

Valid operations:

• tarantool.Datetime + tarantool.Interval = tarantool.Datetime
• tarantool.Datetime - tarantool.Interval = tarantool.Datetime
• tarantool.Datetime - tarantool.Datetime = tarantool.Interval
• tarantool.Interval + tarantool.Interval = tarantool.Interval
• tarantool.Interval - tarantool.Interval = tarantool.Interval

Since tarantool.Interval could contain month and year fields and such operations could be ambiguous, you can use adjust field to tune the logic.

• tarantool.IntervalAdjust.NONE -- only truncation toward the end of month performed (default mode).

  >>> dt = tarantool.Datetime(year=2022, month=3, day=31)
  datetime: Timestamp('2022-03-31 00:00:00'), tz: ""
  >>> di = tarantool.Interval(month=1, adjust=tarantool.IntervalAdjust.NONE)
  >>> dt + di
  datetime: Timestamp('2022-04-30 00:00:00'), tz: ""
  

• tarantool.IntervalAdjust.EXCESS -- overflow mode, without any snap or truncation to the end of month, straight addition of days in month, stopping over month boundaries if there is less number of days.

  >>> dt = tarantool.Datetime(year=2022, month=1, day=31)
  datetime: Timestamp('2022-01-31 00:00:00'), tz: ""
  >>> di = tarantool.Interval(month=1, adjust=tarantool.IntervalAdjust.EXCESS)
  >>> dt + di
  datetime: Timestamp('2022-03-02 00:00:00'), tz: ""
  

• tarantool.IntervalAdjust.LAST -- mode when day snaps to the end of month, if happens.

  >>> dt = tarantool.Datetime(year=2022, month=2, day=28)
  datetime: Timestamp('2022-02-28 00:00:00'), tz: ""
  >>> di = tarantool.Interval(month=1, adjust=tarantool.IntervalAdjust.LAST)
  >>> dt + di
  datetime: Timestamp('2022-03-31 00:00:00'), tz: ""
  

Tarantool does not yet correctly support subtraction of datetime objects with different timezones [2] and addition of intervals to datetimes with non-fixed offset timezones [3]. tarantool-python implementation support them, but it could be reworked later if core team choose another solution.

1. https://github.com/tarantool/tarantool/wiki/Datetime-Internals#interval-arithmetic
2. Datetime with timezone subtraction tarantool#7698
3. Interval ariphmetic with offset change tarantool#7700

Closes #229

[oleg-jukovec]

Thank you for the patch! I don't see a critical problems, just few issues.

[oleg-jukovec]

Wil the test fail on a new versions of Tarantool with fixes? It seems better to skip the test.

[DifferentialOrange]

Yes, it will. I think it's better to wait until the bug would be fixed and then replace xfail with conditional xfail based on version rather than set a skip and forget to ever run the test.

[oleg-jukovec]

Maybe we should run the test only on CI? (by a environment variable or an another way that unittest support)

On the one hand, we'll see when our tests break. On the other hand, a user will not be confused with a failed test after updating Tarantool.

It looks a bit tricky, but for me it seems better than failed by default tests in the future.

[DifferentialOrange]

On the other hand, a user will not be confused with a failed test after updating Tarantool.

I think that when one should get this fail, it would be the moment we need to replace xfail with conditional xfail based on version.

[oleg-jukovec]

We will need to add a task to a sprint, fix it, and then release a new version... It may take a long time for users to get a working version.

It's not a good idea to make CI easier for us in the moment, but make life harder for users in the future.

[DifferentialOrange]

I don't get how choosing between xfail and skip affects user with release versions.

[DifferentialOrange]

If you are running module tests, you are a developer. As a developer, you may either ignore a couple of failing tests after you find out what's the reason (it shouldn't be complicated since relevant issue link is provided), or report the issue to us (to be honest, I'm sure that developer would already be one of us), or fix it (it's an hour long work together with all required stuff like commit messages and PR).

[DifferentialOrange]

I would be glad to provide skip tests with conditions, but these conditions not yet exist. Make a test that always will skip until one remembers to "uncomment it" is also doesn't seems like a good approach to me.

[oleg-jukovec]

LGTM.