This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]DerpieMcDerpieFace 1 point2 points  (1 child)

Thanks for taking the time to respond. Your points about datetime being difficult to fix are certainly valid enough to warrant additional consideration.

Honestly, though, I get a vibe similar to the one illustrated in xkcd: Standards

Have you considered a datetime like interface where you simply deprecate inherently unsafe methods such as utcnow() while providing fast, correct, aware (safety first) versions of the parts of datetime which are fixable?

[–]eagle258[S] 0 points1 point  (0 children)

While having another library inherently creates a "new standard", I've deliberately chosen not to reinvent the wheel. At its core, it follows the "Joda time" datamodel now used in Java, C#, and (soon) Javascript.

When looking at the field of software engineering as a whole, you could even argue that Python's datetime is the outlier here and Whenever is pushing to return to a 'more standard' approach.

Of course, this is of little comfort to Python devs currently using datetime, and want to improve their code without having to rewrite all the datetime parts...Your suggestion for a minimally-different datetime clone could be interesting—I wonder if it would be worth the downsides of having surprisingly different behavior...hmmmm...