4 ms·

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 stu

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.

bapak 1y ago
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.
yes_man 1y ago
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
- popoflojo 1y ago
  Leap seconds are when it really gets fun.
  - gus_tpm 1y ago
    I will never not be impressed with how well we are able to keep track of time in the world
taneq 1y ago
Exactly. It’s not hard, just annoying.

bapak 1y ago

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.

yes_man 1y ago

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

popoflojo 1y ago
Leap seconds are when it really gets fun.
- gus_tpm 1y ago
  I will never not be impressed with how well we are able to keep track of time in the world

taneq 1y ago

Exactly. It’s not hard, just annoying.