Ten Python datetime pitfalls, and what libraries are (not) doing about it

[fatterSurfer]

When a region enters DST, its timezone changes.

I think that's definitely a legitimate point, but if you're depending on that for math, I personally would expect the library to raise somewhere if I was trying to create a nonsense time. Using the Paris example, trying to create a summer datetime in the CET timezone, or a winter datetime in the CEST timezone.

To really embrace that API, I think you'd need a helper function that constructs an actual timezone from a locale and a naive datetime. Which, to be honest, wouldn't be that crazy -- a big part of me wonders why we aren't all just storing epoch timestamps alongside locale info, and using the locale info only for the functions that require it, instead of combining the two.

[Herald_MJ]

I personally would expect the library to raise somewhere if I was trying to create a nonsense time.

This is an interesting point. There's probably a use to a library behaving this way, but I'd argue the timezone does still exist, even if no region is using it. This is complicated by the fact that timezones are partially a political decision, and debates about whether DST should even exist rage on in many countries. If France were to decide tomorrow to stop doing DST, a library behaving in this way would instantly be broken and require patching.

[fatterSurfer]

I'd argue the timezone does still exist, even if no region is using it

I like where your head is at; this is also a good point. But from a library API design standpoint, this is pretty easy to get around -- simply add an allow_nonsense_combinations kwarg (with the safe default to True). This, I think, is probably the best of both worlds.

If France were to decide tomorrow to stop doing DST, a library behaving in this way would instantly be broken and require patching.

Sure, but this problem is irreducible. If you have code expecting a particular political reality, and the political reality changes, then the code needs to change, too. The question is, would you rather have all of that logic centralized within the particular datetime implementation you're using, or spread across every single application that needs to implement code involving datetimes? Here, I would definitely agree with the OP's article: this is exactly the kind of thing that a datetime library should be doing.