[grawlinson]

This kind of stuff really needs to be made explicitly clear in any/all API documentation as it inevitably leads to underlying issues later down the line. It's amazing how something as "simple" as official time/date libraries still have footguns like these.

I'm not bashing anyone that's involved as I realize we're all human and prone to mistakes, I just wish we could all do better.

[oefrha]

Both datetime.utcnow() and datetime.utcfromtimestamp() have red box warnings in the documentation. People copying code from StackOverflow won’t see them, of course.

I should mention that the warnings are relatively recent, added in 3.8.

https://docs.python.org/3/library/datetime.html#datetime.dat...

[EdwardDiego]

Datetime APIs are ridiculously hard.

I suspect that the author of Jodatime (which effectively became the java.time API), who was notorious for being almost Linus Torvalds like in his attitudes and approaches, was probably once a very nice and kind individual. Until he started implementing a datetime library.

I mean, he nailed it, but at what cost? java.time.* is my second favourite datetime API, the first being Postgres'.

I'm actually surprised the source code of Jodatime isn't entirely in Zalgotext, technically it'd be valid Java code (I'm pretty sure, anyway).

[quickthrower2]

When dealing with any date-time library in any platform I find it best to reread the documentation almost every time I use it.

[eusto]

I bet you learned that the hard way.

It's surprising how poorly the situation with timezones is understood in the industry.

[radicalbyte]

Same here - it's why I like working with languages which feature IntelliSense. The documentation is right there in your IDE as you're working.

[9wzYQbTYsAIc]

I’d second that recommendation.

[radicalbyte]

Most languages have something similar, that's why it's important to use static analysers as part of your process to identify usage errors. Everyone is human, mistakes happen. Having tooling as a backup is great.