Live data from Hacker News

Never write your own date parsing library

zachleat.com

121–130 of 333 posts

Re: Never write your own date parsing library

#121
This article doesn't get into some of the special fun of ISO 8601, including relative values, non-Gregorian values, durations...

Some of the things in the standard are surprising, like maybe were a special request. At the time, I commented, something like, Somewhere, in the French countryside, there is a person who runs an old family vineyard, that is still stamping their barrels with the timepoint information [...]. And that person's lover was on the ISO 8601 committee.

(I once wrote an time library in Scheme that supported everything in ISO 8601. It did parsing, representation, printing, calendar conversion, and arithmetic. Including arithmetic for mixed precision and for relative values. It was an exercise in really solving the problem the first time, for a core library, rather than cascading kludges and API breakage later. I don't recall offhand whether I tried to implement arithmetic between different calendar systems, without converting them to the same system.)

Re: Never write your own date parsing library

#122

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

Software companies make money by providing value to their customers via the software they provide. How does reimplementing a hard but already well-solved problem align with their goals? How does that compare with solving a hard problem for which there are no good solutions yet?

Re: Never write your own date parsing library

#123
post #58

Earlier quoted context omitted.

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.

Consider it a translation convention. There's a time and a place for "cycles" or "rels" or whatever, but it gets into "Calling a Rabbit a 'Smeerp'" [1] territory pretty quickly. The payoff isn't really all that great. Stargate SG-1 is one of my favorite instances of this. The first couple of episodes address the fact that the Earth characters do not speak the same languages as everyone else in the galaxy. Then, havin…

"The Hunt for Red October" had an interesting way of handling this with the Russian speakers. The movie starts with them speaking Russian with English subtitles, does a slow zoom into the Russian-speaker's lips, and switches to English mid-sentence.

Re: Never write your own date parsing library

#124

Earlier quoted context omitted.

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…

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.

Nah, finding that stuff is what users are for.

Re: Never write your own date parsing library

#125

Earlier quoted context omitted.

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…

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.

In order to have these mature libraries, someone hat to start building them. They all had to to be incomplete, immature and horribly buggy early in their lifetime, too.

Re: Never write your own date parsing library

#126
post #58

Earlier quoted context omitted.

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.

Consider it a translation convention. There's a time and a place for "cycles" or "rels" or whatever, but it gets into "Calling a Rabbit a 'Smeerp'" [1] territory pretty quickly. The payoff isn't really all that great. Stargate SG-1 is one of my favorite instances of this. The first couple of episodes address the fact that the Earth characters do not speak the same languages as everyone else in the galaxy. Then, havin…

Like in Game of Thrones when Davos was trying to learn to read and incorrectly pronounced the word "knight" the way it was spelled - somehow I could accept that everybody in a fictional universe spoke English except for all the ones who spoke other fictional languages, but I drew the line at words being spelled the same as well.

Re: Never write your own date parsing library

#127

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

This past 22nd of July was the shortest recorded day [0]. How would your library handle this? [0] https://www.space.com/astronomy/earth/earth-will-spin-faster...

Answer: not at all, unless I had to deal with astronomical time to compute locations of celestial bodies with high precision.

Re: Never write your own date parsing library

#128
post #102

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.

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.

Re: Never write your own date parsing library

#129

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 get wanting to do hard things, but do you write in binary? Do you crank your own electricity? My most valuable resource is time. Sure, I could learn more low-level aspects of my craft ... and sometimes I find it useful to do so. When I focus on doing the hardest, already solved things by re-implementing them my own way, what value am I adding? I've never met a client who cared about a library or how I did something…

People have built tables but I still build tables myself. Not as many people will use them as people who use IKEA tables, but that’s okay, I’m still going to build them.

Re: Never write your own date parsing library

#130
I'm not even a programmer, but I can tell that dates are ambiguous a lot of the time.

e.g. dd/mm/yyyy (British) and mm/dd/yyyy (USA) can be confused for the first twelve days of every month.

So, given the high volume of international communication, I think we should hand-write months in full, or at least as the first three letters (Jan, Feb, Mar, ..., Dec)

We should also abandon three-letter acronyms (but that's another story).

Post reply on HN