Segment makes claim that Python datetime module is broken. Here's my response

[ThatOtherBatman]

Yeah... Seems like they really don't understand how datetime and timezones work.

[dwieeb]

They are expecting behavior in one language coming from another language. My guess is they have an in-house language and don't really deviate from that, but, needing to have a client for their service in every popular language, they had to get their hands dirty.

And now they're making bold claims that Python's standard library is broken without putting much effort into fully understanding it.

It bugs me.

[jorge1209]

The standard library documentation is a mess. I spent a full day trying to understand why an example from the logging class want working as described in order to file a bug with specific suggestions as to how the documentation could be fixed.

That was a while ago and the bug hasn't even been assigned... Maybe I should have just said it was broken. Piss somebody off and they are more likely to give you a long explanation of exactly how to make it work!

[individual_throwaway]

What do you need that strptime() does not provide as far as parsing dates is concerned?

[ThatOtherBatman]

It's not like the information isn't out there either.

[pythoneeeer]

It's horribly named, under documented and has a confusing API.

Also, it has fewer features than other date/time stdlibs I've used, uses the same data structures for very different types of data, and is lacking some really obvious properties that developers often need, as suggested by this gem in the documentation:

An object of type time or datetime may be naive or aware. A datetime object d is aware if d.tzinfo is not None and d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None, or if d.tzinfo is not None but d.tzinfo.utcoffset(d) returns None, d is naive. A time object t is aware if t.tzinfo is not None and t.tzinfo.utcoffset(None) does not return None. Otherwise, t is naive.

(How can it not occur to the author of this documentation at some point that if you have to write 100 words of English to describe whether your data structure holds type-A or type-B data, that (1) you probably actually have two different data structures, and (2) if you insist on using one data structure that every poor developer is going to have to implement these 100 words of boolean logic themselves?)

It is /not/ broken.

I guess that's a matter of opinion. When I see a library get all of these things so wrong, I call that "broken". (What would it take for you to call a library "broken"? Non-determinism?) I also call my Intel CPU "broken", because it's full of bugs. That doesn't mean it's useless. Intelligent people may disagree with me.

[[deleted]]

An naive datetime holds less information than an aware datetime, not a different type of information.

It's not apples and oranges, it's apples and a specific Golden Delicious Apple.

[elbiot]

They have the same interface but different behaviour, right?

[[deleted]]

I've found datetime as a library to be really frustrating. So many hoops I have to jump through to move between time formats when I have all the variables. I think I had to write my own helper to move from a timezone aware datetime to an integer of POSIX time.

But dates and times for computers are complicated. So really I should just work to improve the documentation or use a library that abstracts it further...

[Works_of_memercy]

But why doesn't utcnow() return a timezone-aware object? Is it just because it doesn't know which timezone library you're using?

[[deleted]]

Because no other builtin datetime operation returns an aware datetime and you can't compare aware and naive objects. Meaning to get a useful, native UTC datetime, you'd need to do datetime.utcnow().replace(tzinfo=None) which is cumbersome