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

241–250 of 333 posts

Re: Never write your own date parsing library

#241

Post by dguest »

rootsu wrote: post #237
dguest wrote: post #33

Earlier quoted context omitted.

Wait so one day over the new year is 2025-01-01 - 2024-12-31 = 20250101 - 20241231 = 8870 i.e. 90 months and 10 days or 7 years 6 months and 10 days How is that the same thing as one day?

They might be subtracting taking first 4 digits and the subtracing yyyy-yyyy, mm-mm and dd-dd.

Which sort of works, but then you also have to deal with the cases where the days or months go negative (at the month and year bounds), and that also involves knowing how many days there are in each month. It's pretty difficult for me to imagine how this could be easier than just converting to e.g. unix time and subtracting seconds.

Re: Never write your own date parsing library

#242

Post by Latty »

bdhcuidbebe wrote: post #226
chii wrote: post #197

Earlier quoted context omitted.

> The only way to learn how to do hard things, is to do hard things, so do the hardest things. and i don't want to pay my employees to learn, i want to pay them to produce output i can sell. Doing hard things are good, if this hard thing has never been done before - like going to the moon. Doing hard things which has been done, but just not by you, is not good unless it's for "entertainment" and personal development…

> i don't want to pay my employees to learn Then how do you expect them to learn? Good luck getting more blood out of that stone, smh.

Let's be a little charitable and assume they mean just learn. There are hard tasks you can learn from that also provide something you can't just get off the shelf, rather than just reimplementing the wheel.

Re: Never write your own date parsing library

#243

Post by gjm11 »

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 find this a perplexing comment in view of the fact that almost all of the linked article is in fact about how the author wrote his own date parsing library; the "never do it" bit is just a couple of lines at the start and so far as I can tell is mostly there for fun.

(In particular, at no point does the article actually argue for not writing your own date parsing library. It just says, in essence, "Never do it. I did it. Here's what I did and why.")

Re: Never write your own date parsing library

#244

Post by [deleted] »

what wrote: post #184
poink wrote: post #180

Earlier quoted context omitted.

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

You typically take medication at a set time every day. You don’t need to parse dates for that.

[deleted]

Re: Never write your own date parsing library

#245

Post by jillesvangurp »

ttiurani wrote: post #230
jillesvangurp wrote: post #220

IMHO, ISO 8601 as a standard is way too broad and unspecific. ISO 8601 is way too messy. Telling somebody that they need to parse an ISO 8601 date time is not enough information to do the job. Which variant is it? Does it include the time part. IMHO allowing the full range of ISO 8601 dates and times in a data format is usually a mistake. You want to be more specific. There's a need for a standard that locks down the…

> You can use datetime libraries that are widely available to localize timestamps as needed in whatever way is required locally. But timestamps should get stored and transmitted in a normalized and 100% unambiguous way. If by "timestamp" you mean past dates and deterministic future dates, then agreed. (Although I prefer unix epoch in ms for those, to be able to use integers and skip string parsing steps completely.)…

> Frankfurt on July 26th 2029 at 1pm

That's a localized date and time. And it shouldn't be what you store but what you present based on the user's preferences. The same calendar event would be completely different in the calendar of a tourist visiting Frankfurt. And calendar invites of course can have multiple participants that each want their date times localized to their time zone and locale. So the best way to do that is to store the time zone in a 100% normalized, unambiguous way that is then transformed into whatever matches the user's preferences as part of the presentation logic.

In the same way, place names are localized. The French would spell Frankfurt as Francfort, for example. Location should be a separate field. And it implies nothing about the locale that should be used for presenting the timestamp or the timezone that should be used. Because Frankfurt is a rather international town and some might prefer MM DD YY instead of DD MM YYYY. Not to mention the use of am/pm vs. 24 hour time. And of course it has a big airport that people use to travel to pretty much all time zones on the planet. Hard coding all that in a timestamp is a mistake. Because now you need needlessly complex parsing logic and transformation logic to fix that mistake. Which is what this article is about.

Re: Never write your own date parsing library

#246

Post by thfuran »

stouset wrote: post #152
avanwyk wrote: post #139

Earlier quoted context omitted.

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.

Nobody is really saying not to build these things. They’re saying the problem is exceedingly annoying to solve—and often not in a technically interesting way but in a way that is just massively tedious—and a better alternative almost certainly already exists. If you want to build it to scratch an itch, go ahead. If you want to build it for fun, go ahead. If you want to build it because an existing solution gets somet…

>If you want to build it because an existing solution gets something wrong and you can do better, go ahead

But please at least file the bug first.

Re: Never write your own date parsing library

#247

Post by atoav »

Well, I did that. And it works flawlessly for a decade now. The thing is just that I know and control the context from which the dates are being parsed. If you're now like: "Yeah ok if you're the one who sends the data being parsed it might be okay", the claim of "never do X" is proven wrong if there are specific situations where soing X is not only okay, but might be the sensible option.

Which is why you should never use the word "never" unless you're really sure you can't come up with a situation that is an exception.

Re: Never write your own date parsing library

#248

Post by Hnrobert42 »

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.

>Maybe be careful

Really?

Re: Never write your own date parsing library

#249

Post by ttiurani »

jillesvangurp wrote: post #245
ttiurani wrote: post #230

Earlier quoted context omitted.

> You can use datetime libraries that are widely available to localize timestamps as needed in whatever way is required locally. But timestamps should get stored and transmitted in a normalized and 100% unambiguous way. If by "timestamp" you mean past dates and deterministic future dates, then agreed. (Although I prefer unix epoch in ms for those, to be able to use integers and skip string parsing steps completely.)…

> Frankfurt on July 26th 2029 at 1pm That's a localized date and time. And it shouldn't be what you store but what you present based on the user's preferences. The same calendar event would be completely different in the calendar of a tourist visiting Frankfurt. And calendar invites of course can have multiple participants that each want their date times localized to their time zone and locale. So the best way to do…

> That's a localized date and time.

Note that I'm not arguing against storing the numeric part in a consistent format, of course you should. My point is that right mow in 2025 you don't know the timezone.

E.g. if you write that as the zones are now, it would be "2029-07-26T11:00:00.000Z", but if the timezones change, then when a person is looking at their calendar in 2029, they will be an hour early or late to the meeting.

So it's not about presentation of the timestamp, it's that the timestamp does not match what the user meant.

> In the same way, place names are localized.

I beg to disagree. All spellings refer to the same phyysical place, but you can't guarantee my example timestamp description and a simple ISO time representation without a geolocation will refer to the same singular point in time.

Re: Never write your own date parsing library

#250

Post by UltraSane »

skrebbel wrote: post #235
ceejayoz wrote: post #78

Earlier quoted context omitted.

> The payoff isn't really all that great. If you’ve read David Weber’s Safehold series, this point gets super clear. It's written with names like "Zherald Ahdymsyn" (Gerald Adamson), but that makes it quite the slog for many.

I could not get through Banks’ “Feersum Endjinn” for this sole reason. English isn't my first language, though I’m fluent in it and read lots of hard sci-fi in it. But half a book using English “spelling rules” applied haphazardly just to make a minor point about one character was well beyond my capacity. I quoted “spelling rules” on purpose because let’s be honest, English doesn’t really have any. You couldn’t trans…

As a native speaker I found it pretty easy to read.
Post reply on HN