> We don't want a world where only three old bearded guys can write a compiler or a physic engine.

Don't write your own OS does not mean do not contribute to something like the linux kernel.

Well don't do it and instead of using an off the shelf library that is known to work while the rest of the development team isn't reinventing the wheel. Doing it for fun and education is fine of course.

What IS the right way to model dates in a pacemaker ...? I hope the answer is "just don't do it" -- but I don't know what reasons there might be for a pacemaker to need to depend on calendar dates in order to best do its job ...

>Maybe be careful

Really?

It's interesting that people are disagreeing with you in a way that they're making it sound like they're elaborating on your point.

To the people reading this, please don't just disagree with an "obvious counterexample". Explain why!

I would not be surprised if the state of unit tests on good date parsing libraries are not sufficient to design a new one from scratch.

See the number of unit tests in the Linux kernel, for example.

> Having said that, I don't think date libraries are hard, I think they're messy.

Messy is just a particular kind of tedious which is the most common form of hard.

It's not like typical things that need doing tend to include solving lots of unsolved problems.

Most well-known date library systems have failed in places. Quite a few, still do. So whilst you might get some known regression to test against, nothing can give you a foolproof guide.

You can have reasonable confidence that here there be dragons, but not so much that your assumptions about something will hold.

And that dude is no longer actively maintaining it and you just discovered an issue with it.

> If nobody makes them, then how is that going to work?

I see it as “Dont write your own X, unless you want to maintain X. Here be dragons, this problem is deeper than it appears, the first 80% will be easy, the next 15% will annoy you, and the last 5% will consume your life for weeks, months, or even years. Or you could use a library”

It's about exposure.

The things that people write that everyone uses have had HUGE exposure.

They've been exposed to all the edge cases, they've been tested millions, if not billions of times. All the bugs ironed out.

The people who've worked on them are now the greatest domain experts on that little corner of comp-sci.

Yours won't unless it hits prime time.

So yours will be weak, brittle and dangerous.

I think there is missing point in this discussion.

Most of the time you build something else.

Like if you build a todo app and have to deal with scheduling you don’t spend time making date library because it’s not your goal. But people would do that.

Heck most developers instead of starting blog on a blog platform start writing code for their own blogging engine.

Holy shit.

The point is, before you release your new thing, make sure it addresses all of the pain points the previous solutions have already slogged through,

or that if it doesn't, people are still aware of when they can arise, and why your thing has chosen not to mitigate them yet,

or ever, if it's an opinionated piece of tech.

Correct date handling (including parsing) can be monumentally important. Imagine an app that reminds people when to take their medications, for example

A lot of cryptography relies on dates, time, etc.