Possible bug in .subtract() across a DST change

[ppentchev]

• I am on the latest Pendulum version.
• I have searched the issues of this repo and believe that this is not a duplicate.

• Debian GNU/Linux testing (post-bookworm, pre-trixie):
• 3.0.0:

Issue

First of all, thanks a lot for writing and maintaining pendulum!

While playing around with a couple of edge cases, I seem to have stumbled upon a bug in DateTime.subtract() and either a bug or my misunderstanding about the way DateTime.add(days=N) should work across a DST change. I'm attaching a Python source test file (test_sofia_dst.txt) that uses pytest.mark.parametrize() to get closer and closer to the DST change time for Sofia, Bulgaria, earlier this year.

The subtraction problems

Starting from a timestamp in mid-August 24, and subtracting several different time intervals from it, I expected to get exactly to
the time after the DST change (04:00:00 on 2024-03-31) and then, subtracting an interval a second longer, to get to the time just before the DST change (02:59:59 on 2024-03-31). The 04:59:59 result surprised me, as did the result of subtracting a longer interval.

This is the short output from pytest. The values on the right are the ones I expected to get.

FAILED tests/unit/test_sofia_dst.py::test_subtract[tcase4] - assert (2024, 3, 31, 4, 59, 59) == (2024, 3, 31, 2, 59, 59)
FAILED tests/unit/test_sofia_dst.py::test_subtract[tcase5] - assert (2024, 3, 31, 4, 21, 47) == (2024, 3, 31, 2, 21, 47)
FAILED tests/unit/test_sofia_dst.py::test_subtract[tcase6] - assert (2024, 3, 31, 2, 21, 47) == (2024, 3, 31, 1, 21, 47)

The possible addition problem

I'm not sure if .add(days=N) is supposed to add 24-hour periods across a DST change, or merely increment the date; it seems to do the latter, but maybe that is intended behavior.

FAILED tests/unit/test_sofia_dst.py::test_add[tcase4] - assert (2024, 4, 3, 2, 21, 47) == (2024, 4, 3, 3, 21, 47)

If something goes wrong with these files, they are also available in a GitLab repository.

Thanks in advance for your time, apologies if this is actually a duplicate report, and keep up the great work!

G'luck,
Peter