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

291–300 of 333 posts

Re: Never write your own date parsing library

#291

Post by yes_man »

mikepurvis wrote: post #282
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,…

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

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

Re: Never write your own date parsing library

#292

Post by breatheoften »

kuon wrote: post #238
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.

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.

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

Re: Never write your own date parsing library

#293

Post by drewcoo »

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

There's hard and then there's "there are so many unexpected edge cases you'll surely be cut if you touch that code," which not fun-hard.

This is the latter.

Re: Never write your own date parsing library

#294

Post by msla »

Arainach wrote: post #48
TheJoeMan wrote: post #35

Earlier quoted context omitted.

It's funny to reason why we must go to bed when the clock has a certain number, since modern technology could easily be programmed to adjust as needed. No technical reasons the Martians can't go to bed at 9:00am today and 9:40am tomorrow. This mirrors my thoughts on why farmers caring about daylight savings time is farcical, farmers I know use the timekeeping of "crack of dawn" and "sunset".

People want to understand when things are open/reasonable without having to do a lookup every time. A conversion has to happen somewhere - either I can say "X is in timezone foo. It's 1300 there so they're awake and I can call them" or "It's 1900 UTC, X is awake from....err....2200 to 1400, so I can call now". The first is significantly easier as it requires remembering only a single offset and then going with societ…

> "It's 1900 UTC, X is awake from....err....2200 to 1400, so I can call now"

Assuming it's that simple of course. Like, you can do mental math about what UTC "officially means" for someone many miles away, but people coordinate with others even if it means their local schedule is not aligned with that ideal case. Time zones account for this by being wider or narrower than their Platonic 15° of longitude ideal in some places.

Re: Never write your own date parsing library

#295

Post by Clamchop »

alex_c wrote: post #108
takinola wrote: post #79

No other programming concept has caused me more grief than dealing with time and timezones. It starts to get really mind-bendingly complex once you start thinking about it deeply. That is even before you start encountering the quirks (some places have timezone changes that depend not only on the time of year but also on the actual year). Lesson learnt - choose a library (moment is great) and never think about time ag…

Except you do still have to think about time, no matter what… Libraries will help with the really messy details, but even the high level requirements have a lot of pitfalls. “Simple” example that anyone who’s ever worked on a scheduling application will probably be familiar with: “Get a list with all of today’s events.” Well, whose “today” (timezone) are we talking about? Server, client, setting in the user account?…

I understand the complexity of time, but this scenario doesn't seem all that difficult. Any user expects (I won't get into what they want) to be shown _their_ day, and they expect it to be local calendar time. You _might_ want to show wee hours events, from midnight to just short of 5am. Apps like Teams do a good job of spacially illustrating time as it matters to you _and_ as it matters to others.

Re: Never write your own date parsing library

#296

Post by fc417fc802 »

breatheoften wrote: post #292
kuon wrote: post #238

Earlier quoted context omitted.

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.

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

Well naturally it will need to connect to your phone via Bluetooth for the app to proxy update downloads and historic location data uploads. But in order to do anything on the network securely you need an accurate clock and the ability to parse datetimes because the PKI implementation depends on that.

Then the app pings you to remind you that your premium subscription will be expiring soon after which your heart rate will be limited to 100 bpm or less.

Re: Never write your own date parsing library

#297

Post by kulahan »

gmueckl wrote: post #185
kulahan wrote: post #164

Earlier quoted context omitted.

Why would I mature yours and deal with those issues when I can just use the already-mature one?

You assume that you always have a mature option available. That's (a) definitely not a totally generalizable assumption and (b) my point is that mature options only exist because the people that developed them just did it when confronted with the task.

We are specifically talking about something that does have a mature option available. That’s why it’s stupid to try and implement your own version of something complex.

If you change the story such that the product is actually needed and universally immature, of course building it is a valid argument.

Regarding b: Right, and the point of this article is that for those types of things, go for the already-mature thing. You’re arguing a point nobody is making.

Re: Never write your own date parsing library

#298

Post by fc417fc802 »

leakycap wrote: post #188
ok_dad wrote: post #168

Earlier quoted context omitted.

I mean, a table is as hard as you make it. I work with rough construction lumber, and make nice finished goods, my point was that people still do stuff that isn’t worth their time financially.

> I mean, a table is as hard as you make it. We aren't talking about the same thing: I stated "I don't think tables are the hard thing." Note the word "the" in front of "hard thing" -- I'm referencing the article we're discussing, which mentions "the hard thing"

The entire process is "the thing". In the case of a table by adjusting the inputs to the process you can cover quite a wide range of difficulty and required time.

For example, start from a felled tree, use only hand tools, and assemble using medieval joinery techniques. Building a table that way is quite hard by modern standards.

Now if you'll excuse me I need to get back to writing this date parsing library in assembly.

Re: Never write your own date parsing library

#299

Post by ahartmetz »

Swizec wrote: post #114
ramijames wrote: post #109

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…

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

The latter, if you want to get it completely right. I occasionally read the commits in the Qt framework, and from that, I can tell you that date-time stuff is complicated, and not in an instructive way, but in a super tedious way.

Re: Never write your own date parsing library

#300

Post by junon »

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

Writing an OS. I've learned more about computers, hardware, CPU design, compilers, etc. that have translated into literally every other facet of my IT world than I could have done without this project.

Definitely agree.

Post reply on HN