Subtraction of two datetime objects returns wrong timedelta

[Iftakharpy]

Bug report

Bug description:

The difference of the date time objects returns timedelta in days, which should instead return the smallest accurate unit like milli/micro/seconds in time.

Example code:

from time import sleep
from datetime import datetime as dt, timedelta as td

end_time = dt.now() + td(seconds=2)

while (end_time - dt.now()) >= td(seconds=-1):
    sleep(1/2)
    print(f"end({end_time}) - now({dt.now()}) => timedelta({(end_time - dt.now())})")

Output:

end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:45.161281) => timedelta(0:00:01.499564)
end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:45.661931) => timedelta(0:00:00.998914)
end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:46.162610) => timedelta(0:00:00.498235)
end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:46.663169) => timedelta(-1 day, 23:59:59.997676)
end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:47.164116) => timedelta(-1 day, 23:59:59.496729)
end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:47.664745) => timedelta(-1 day, 23:59:58.996100)

The output I am expecting should be something like below:

end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:45.161281) => timedelta(0:00:01.499564)
end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:45.661931) => timedelta(0:00:00.998914)
end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:46.162610) => timedelta(0:00:00.498235)
end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:46.663169) => timedelta(-0:00:00.997676)
end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:47.164116) => timedelta(-0:00:01.496729)
end(2024-08-10 13:18:46.660845) - now(2024-08-10 13:18:47.664745) => timedelta(-0:00:02.996100)

CPython versions tested on:

3.12

Operating systems tested on:

Linux, Windows

[barneygale]

This is expected behaviour according to the docs

days, seconds and microseconds are then normalized so that the representation is unique, with

• 0 <= microseconds < 1000000
• 0 <= seconds < 3600*24 (the number of seconds in one day)
• -999999999 <= days <= 999999999

[...]

Note that normalization of negative values may be surprising at first. For example:

>>> from datetime import timedelta
>>> d = timedelta(microseconds=-1)
>>> (d.days, d.seconds, d.microseconds)
(-1, 86399, 999999)

To support negative seconds, we'd need to either change the timedelta normalization, or allow unnormalized timedelta objects.

[terryjreedy]

The proposed change in possible timedelta objects is unclear to me because I do not exactly understand the verbal description while the examples a) do not show proposed timedelta attributes but show string transformations that combine them and b) do not cover the entire range of possible negative results. Only '-1 day' results are covered, in which case the absolute value has '0 days', which is not displayed.

Are you really concerned about the attributes of timedeltas or of their string representation? If the latter, write your own tdstr function to handle negative day results, or possibly just -1 day results.

If the former, this proposal is, as Barney explained, not a bug report, but either:

A) a backwards incompatible feature change request to always change the output for negative differences. This is extremely unlikely to be accepted, as it requires persuading core developers and at least some users that the current choice is so wrong as to warrant suffering the required deprecation process.

B) a feature addition request to optionally get a different output. This would mean adding a new keyword AND a new attribute to timedeltas to indicate which normalization it has AND new code to all operations# to handles all possible combinations of argument normalizations AND decisions as to which normalization should be used for each possible combination of inputs. This also means that users of timedeltas might have to deal with both possibilities.

Selecting a single canonical or normalized form for equivalent forms of values is extremely common in math and programming and has immense benefits. One of the pains of Unicode is multiple normalizations and the fact that unicode strings are not tagged and may even have multiple normalizations within the same string.

I therefore think this issue should be closed, and recommend against posting this proposal on discuss.python.org.

[Iftakharpy]

I am concerned about getting wrong attributes like days and seconds returned from the calculation. I will get wrong results if I do further calculations on the returned value. This issue occurs due to the way divmod works for negative numbers. The issue propagates from everywhere the divmod function is used.

For example:

cpython/Lib/_pydatetime.py

Line 672 in 363374c

days, seconds = divmod(seconds, 24*3600)

Would it be a reasonable suggestion to implement an alternative function to divmod function to calculate these carrying for timedela?

[Iftakharpy]

This is expected behaviour according to the docs

days, seconds and microseconds are then normalized so that the representation is unique, with

• 0 <= microseconds < 1000000
• 0 <= seconds < 3600*24 (the number of seconds in one day)
• -999999999 <= days <= 999999999

[...]
Note that normalization of negative values may be surprising at first. For example:

>>> from datetime import timedelta
>>> d = timedelta(microseconds=-1)
>>> (d.days, d.seconds, d.microseconds)
(-1, 86399, 999999)

To support negative seconds, we'd need to either change the timedelta normalization, or allow unnormalized timedelta objects.

Can you provide an example on how to produce the correct return value of timedelta instead of the incorrect value it returns by default? Thanks in advance.

[terryjreedy]

Questions about how to use Python should be directed to https://discuss.python.org/c/help/7 where answers can more easily help others.

[Iftakharpy]

I don't have and account on disuss.python.org and I do not want to create one. I would be grateful if someone could answer it here.

[Iftakharpy]

As mentioned in #122880 (comment) the issue arises for the use of divmod. Now my suggested change would be to convert the number we are trying to do carry on into a positive number before the divmod operation, after the divmod operation we can convert the return values into negatives if the number that we were doing carrying on was negative. Does this sound acceptable? If so I can implement a new function to do the carrying calculation instead of using the standard divmod function and send a pull request. @terryjreedy can you reply to this?

[Iftakharpy]

@barneygale, in #122880 (comment) by timedelta normalization do you mean adding time zone info? If so I believe timedelta doesn't have the option to specify time zone info. If you meant that I should create datetime object with time zone info like UTC that does not work either.

In #122880 (comment) I don't know what you meant by allowing unnormalized timedelta objects. Can you please explain it here?