Live data from Hacker News

Never write your own date parsing library

zachleat.com

101–110 of 333 posts

Re: Never write your own date parsing library

#101

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

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

Re: Never write your own date parsing library

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

Re: Never write your own date parsing library

#103

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 in code - until it broke. Then, they didn't care who wrote it, they just cared it started working again.

Re: Never write your own date parsing library

#104

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…

I agree with everything other than "moment is great". Even the devs say don't use it any more, and accidentally mutated datetimes have been the source of bugs in apps I've worked on multiple times. Luxon is great though.

Re: Never write your own date parsing library

#105

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…

The really important thing to remember about timezones is they're not a mathematical construct, or a physics construct, or an astronomy construct... They're a political construct. Framed in that light, they have every bit the complexity of having some piece of your code depend on the law (except it's the law of every nation you expect to be running your code in).

To that point: https://devblogs.microsoft.com/oldnewthing/20030822-00/?p=42...

Re: Never write your own date parsing library

#106

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

Solve new hard things instead of solved hard things.

Re: Never write your own date parsing library

#108

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? Or none of the above, and actually timezone at the physical location of the event, if there is one?

And what does “today” mean, anyway? Truncate the date? 00:00-23:59? Business hours?

And what does “today’s event” even mean? Events can cross midnight… Does an event need to start today? End today? Both? Can events span multiple days?

The fun never ends!

Re: Never write your own date parsing library

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

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.

Re: Never write your own date parsing library

#110

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

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.
Post reply on HN