Some things are good hard, the kind of hard that's driven by an interesting domain, going deep with well-architected tools or systems, learning lots of cool stuff.

I expect datetime-adjacent code is basically the opposite of all of this. All the hard parts are driven by fiddly adherence to real-world geography, politics, physics/astronomy, etc. There's no underlying consistency from which a sane model can be extracted, it's just special cases and arbitrary parameters all the way down.

I'm up for a challenge of course, but all else being equal, I'm happy to leave work that is the "bad hard" to others.

Reminds me of this passage from Postgres documentation:

”As an example, 2014-06-04 12:00 America/New_York represents noon local time in New York, which for this particular date was Eastern Daylight Time (UTC-4). So 2014-06-04 12:00 EDT specifies that same time instant. But 2014-06-04 12:00 EST specifies noon Eastern Standard Time (UTC-5), regardless of whether daylight savings was nominally in effect on that date. … To complicate matters, some jurisdictions have used the same timezone abbreviation to mean different UTC offsets at different times; for example, in Moscow MSK has meant UTC+3 in some years and UTC+4 in others.”

Parsing datetimes indeed sounds like a challenge in collecting, knowing and maintaining all these warped out standards and compromises. ”Bad hard” is a great description

Correct. It's not hard, just stupidly time consuming to the point of being unable to ever produce anything that works 70% of the time.

I hate anyone who will attempt to craft their own 10-lines line parser and then ignore that it fails 4 times a day. Just use the damn library. Thank you.

Write it for fun, but don't ship it. You're wasting everyone's time with your craft.

Exactly. It’s not hard, just annoying.