Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never write your own date parsing library

zachleat.com

Post reply on HN
Print view View original

131–140 of 333 posts

Re: Never write your own date parsing library

#131

Post by ozim »

ramijames wrote: post #109
glibby wrote: post #102

Earlier quoted context omitted.

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.

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 absolu…

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.

Re: Never write your own date parsing library

#132

Post by [deleted] »

glibby wrote: post #102
quelsolaar wrote: post #100

When ever i see "never implement your own...", i know i want to implement it myself. People say that about hard things, and I only want to do hard things. Nobody wants people who can do easy things, people want people who can do hard things. The only way to learn how to do hard things, is to do hard things, so do the hardest things. So go ahead, write your own date library, your own Unicode font rendering, compiler,…

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.

[deleted]

Re: Never write your own date parsing library

#133

Post by mpyne »

alexanderchr wrote: post #111
jabroni_salad wrote: post #42

Earlier quoted context omitted.

In mainframes, Julian dates are popular for that reason. YYDDD (day of year). When is 30 days after today? 25206+30

Maybe I’m missing something but then what is 30 days after Christmas? 25389?

25389 mod 365, presumably. The very fancy mainframes probably would pick the appropriate modulus based on whether it was a leap year or not.

Re: Never write your own date parsing library

#134

Post by benlivengood »

flir wrote: post #128
glibby wrote: post #102

Earlier quoted context omitted.

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.

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.

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.

Re: Never write your own date parsing library

#135

Post by boothby »

quelsolaar wrote: post #110
fsckboy wrote: post #101

Earlier quoted context omitted.

you want to do something people really think is hard? use C. it's not safe. all the people who say C is not safe have downvoted me for quoting them

I exclusively write in C89. I'm a member of the ISO C standard board.

The confluence of tinker-for-tinkerings'-sake "hackers" and get-rich-quick "hackers" on this site certainly leads to a lot of fun miscommunication.

Re: Never write your own date parsing library

#136

Post by flir »

benlivengood wrote: post #134
flir wrote: post #128

Earlier quoted context omitted.

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.

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.

You might be right, I haven't checked. It just seems on the face of it such an easy thing to test. Scalars go in, scalars come out. (This could just be me doing the Dunning-Kruger thing).

You could run a fuzzer against two libraries at the same time to find discrepancies....... hmm. That might actually be a good exercise.

Re: Never write your own date parsing library

#137

Post by Terr_ »

3cats-in-a-coat wrote: post #49
davidw wrote: post #12

It's like that joke someone posted on Twitter: "I was in favor of space exploration until I realized what it would mean for date/time libraries"

Every time someone mentioned "days" or "months" or "years" in Andor I had to mentally zap my brain not to think about how it doesn't make a sense across a galaxy.

That makes me think of the foreword Isaac Asimov wrote for Nightfall, explaining his choice of terms:

> The essence of this story doesn't lie in the quantity of bizarre terms we might have invented; it lies, rather, in the reaction of a group of people somewhat like ourselves, living on a world that is somewhat like ours in all but one highly significant detail, as they react to a challenging situation that is completely different from anything the people of Earth have ever had to deal with. Under the circumstances, it seemed to us better to tell you that someone put on his hiking boots before setting out on a seven-mile walk than to clutter the book with quonglishes, vorks, and gleebishes.

Re: Never write your own date parsing library

#138

Post by macintux »

I wrote one in Erlang years ago for Riak’s time series implementation. I don’t remember all of the motivations, but most of all I wanted the ability to encode incomplete date/time objects.

https://github.com/macintux/jam

I’d like to get back to it. If nothing else, I dearly miss using Erlang.

Re: Never write your own date parsing library

#139

Post by avanwyk »

quelsolaar wrote: post #100

When ever i see "never implement your own...", i know i want to implement it myself. People say that about hard things, and I only want to do hard things. Nobody wants people who can do easy things, people want people who can do hard things. The only way to learn how to do hard things, is to do hard things, so do the hardest things. So go ahead, write your own date library, your own Unicode font rendering, compiler,…

I can't believe this is such a controversial take. Solving hard things by yourself is growth. I 100% agree, rather solve a hard solved problem yourself than learning yet another JS framework or launching yet another revenue losing SaaS ("successful" because of VC). Or whatever. Push hard boundaries.

Re: Never write your own date parsing library

#140

Post by Terr_ »

kaoD wrote: post #36
QuadmasterXLII wrote: post #2

I ran into date heck recently in a medical setting for storing birthdates. Eventually I settled on the idea that a birthdate isn’t a physical time, it’s just a string. We can force the user to enter it in the format 02/18/1993 leading zeroes and all, and operations on it other than string equality are invalid. We’ll see if this survives contact with the enemy but it’s already going better than storing and reasoning a…

I like how Temporal[0] does this. What you were dealing with is Temporal.PlainDate[1], i.e. a date with a calendar associated but no time or timezone (might be due to being implied but also might be irrelevant, like in birthdates). Temporal has other cool types, each with distinct semantics: - Instant: a fixed point in time with no calendar or location. Think e.g. "the user logged in at X date and time" but valid acr…

I hope that as time goes on software design get better about modeling things that are guesses, conjecture, etc. rather than Absolute Facts.

As-is, we assume lots of things are facts and we just hope it's true enough to avoid problems. (Starting with the business requirements. :p )

Post reply on HN