[glibby]

By all means, write it. Just don't use it. These warnings are almost always in the context of code you're going to release, not exercises in learning on your own.

[kuon]

Hard disagree here. Use it. Of course, if you running code that drive a pacemaker or a train maybe be careful, but in general, do things. We don't want a world where only three old bearded guys can write a compiler or a physic engine. Do the same errors again and you'll learn, eventually you'll do better than those who were here before you.

[sabas123]

> 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.

[patrick0d]

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.

[breatheoften]

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 ...

[Hnrobert42]

>Maybe be careful

Really?

[Zambyte]

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!

[flir]

In the case of date libraries, I think if I ported the tests from a few well-known libraries to my own, I'd have reasonable confidence in my own.

Having said that, I don't think date libraries are hard, I think they're messy. Mostly because humans keep introducing convenience fudges - adding a second here, taking eleven days off there, that kind of thing.

[benlivengood]

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.

[tbrownaw]

> 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.

[shakna]

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.

[bdangubic]

I write my own, but in production I always use libraries written by some dude from Omaha :)

[dylan604]

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

[cmdlyne2]

> By all means, write it. Just don't use it.

I'd say write it, probably don't use it, and don't share it unless it's substantially better than the alternative.

This way, you'll learn about it, but you'll more likely stay with something standard that everyone else is using, and you don't share yet another library that wastes others' time and your own (having to read about it, evaluate it, use it, and the migrate off of it when it's abandoned).

[ramijames]

This is such nonsense. All the stuff that we use, someone wrote. If nobody makes them, then how is that going to work?

The messaging here is that you should be careful about using what you build on your own because it:

- hasn't been battle tested

- likely has bugs

- isn't mature

The only way that it will be all of those things is if someone invests time and energy in them.

From an ecosystem perspective this is absolutely the right thing. You want duplicate projects. You want choice. You want critical knowledge to be spread around.

[Swizec]

> 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”

[mattmanser]

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.

[ozim]

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.

[DANmode]

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.

[bigstrat2003]

I think that advice makes sense in the context of cryptography, where the consequences for getting it wrong can be quite serious indeed. I don't think it holds true for something as unimportant as a date parsing library.

[poink]

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

[leptons]

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