gistfile1.txt

Python 3.8.1 (default, Dec 31 2019, 18:44:59) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> samoa = datetime.timezone(datetime.timedelta(hours=14))
>>> before = datetime.datetime(2011, 12, 29, tzinfo=samoa)
>>> before + datetime.timedelta(days=1)
datetime.datetime(2011, 12, 30, 0, 0, tzinfo=datetime.timezone(datetime.timedelta(seconds=50400)))
>>> 

Thanks!
Your stack overflow comment says "there's your bug. That date doesn't exist".

I'm not yet following.

>>> before.isoformat()
'2011-12-29T00:00:00+14:00'
>>> after.isoformat()
'2011-12-30T00:00:00+14:00'

in what sense it doesn't exist?
is the idea that with the timezone offset it's already in 2012? but December has 31 days, and IIUC that offset actually goes back — translates to '2011-12-28T10:00:00+00:00'?
was there something special about this day in Samoa?

Oh, interesting https://www.bbc.com/news/world-asia-16351377 "Samoa and Tokelau skip a day for dateline change"
👍

However, I wonder if this is just "garbage in, garbage out".
datetime.timezone(datetime.timedelta(hours=14)) does NOT represent the political Samoa TZ, just a fixed 14-hour offset TZ.
Would this bug reproduce with an actual TZ that's faithful to Samoa?

I guess you have a point that I was arguing against dependenceis in direction of "just do it with python stdlib", and the stdlib famoulsly includes no timezones database ☹️
Granted.

But is the conclusion "you must use a real timezone database for human-meaningful results", or is there a fault in using datetime.timedelta(days=1) for going a day back/forward?

[thanks for the interesting discussion, as most programmers, I don't know enough about dates...]

The conclusion is that, unsurprisingly, dates are bullshit, and the less anyone can have to do with them, the better. If someone else has written something to handle dates, use that.

We're Python. We shouldn't be scared of dependencies.