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

301–310 of 333 posts

Re: Never write your own date parsing library

#301

Post by ok_dad »

fc417fc802 wrote: post #298
leakycap wrote: post #188

Earlier quoted context omitted.

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

Not even doing it from scratch is the hard thing, the hard thing is getting the experience to know how to fit stuff together the best way to achieve your design and utilitarian goals, what wood to use, etc.

The hard thing isn’t building the date parsing library in assembly, it’s learning assembly well enough to do it in the first place.

I’m not sure where this discussion began but I was rebelling against everyone who says “just buy it” in regards to anything hard to do.

Re: Never write your own date parsing library

#302

Post by jerf »

tetha wrote: post #72
jerf wrote: post #58

Earlier quoted context omitted.

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…

I think that these fundamental things can be turned into an interesting topic, but you have to try for it. Like, in a story background I'm pushing around, there's a coalition of a large amount of species developed on different planets. And you're a military officer, and you need to coordinate shifts, but - assuming some collectively normalized number of hours - some of your tiny dudes are tuned to 3 hours of sleep, 3…

Some Star Trek books took the opportunity to work multiple species into the Enterprise's roster, when you don't have special effects problems with doing so.

But some others took the approach that Starfleet has a lot of vessels, and they're still somewhat segregated by species just because of those issues, and while the TV series don't corroborate that very well, I think it's better fanon overall. Peace and harmony among the species is great and all but trying to work 17 hour shifts in 2.5 Gs is going to get really old for the humans. And who wants to wear complicated breathing apparatuses for years at a time?

It would be an interesting direction to take a book series in... why do we see so much about the Klingons and Cardassians and Vulcans on TV? It's not because they're the only important species, it's because they're the species that breath our atmosphere at more-or-less our gravity and solar cycles. The Federation could be a whole bunch of parallel Federations-within-a-Federation where there's an entire set of species who also crew with each other but breath methane, need .7G, and work around 14-hour day/night cycles, and they just don't interact much with each other, not because they hate each other but just because it's so tedious to have prolonged contact.

Re: Never write your own date parsing library

#303

Post by taneq »

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…

Exactly. It’s not hard, just annoying.

Re: Never write your own date parsing library

#304

Post by cookiengineer »

GoblinSlayer wrote: post #270
cookiengineer wrote: post #229

Earlier quoted context omitted.

I feel obligated to comment on this. Due to my work I rely on web scraped data for cybersecurity incidents. For Amazon Linux, they are disclosed with the fvcked up US datetime format (Pacific Time) and not in ISO8601 formatted strings which could imply Juliet/Local time. In 2007 there was a new law that changed when Pacific Time enters/leaves Daylight Saving Time. Instead of making this fixed by a specific Day of a s…

Reporting of cybersecurity incidents are easily late by a month or more, time zones are well below the rounding error. You will be more accurate to display it as YYYY±6month.

You seem to be not aware that there are a lot of legal obligations which come with providing this kind of inaccurate data. Especially if things go wrong because of it.

Re: Never write your own date parsing library

#305

Post by popoflojo »

yes_man wrote: post #291
mikepurvis wrote: post #282

Earlier quoted context omitted.

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

Leap seconds are when it really gets fun.

Re: Never write your own date parsing library

#306

Post by geocar »

kaoD wrote: post #287
geocar wrote: post #198

Earlier quoted context omitted.

> 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). It might also be relevant: Ever ask an older Korean person their age? > 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 across the world for any timezone or calendar system. This is what we usually use "U…

Just FYI you were downvoted with no explanation because you missed the point in all of these and you're using a smug and off-putting tone which makes it look like only care about "being right" and not finding what "is right". Also you obviously didn't bother reading the "important concepts" link ([3]). I was going to assume good faith and reply to each of your comments but it'd probably be a waste of time. As a summa…

> FYI you were downvoted with no explanation because you missed the point in all of these

I think people downvote things they disagree with, and I'm not surprised people who think handling dates and times is beyond them are mad at someone exists who doesn't, because I'm calling out their impotence in a way.

And I understand you don't want to feel impotent, so telling me that you're not going to respond to me is a way for you to reclaim some of that.

> just being completely wrong like saying you cannot do reasonable arithmetic with PlainMonthDay

Then prove it: How exactly do you think you can meaningfully add two PlainMonthDays? What does such a thing mean?

I think you don't know what you are talking about, and you somehow think that means I don't either.

Re: Never write your own date parsing library

#307

Post by ainiriand »

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

Yeah but never ever roll your own encryption, or do it but never trust it.

Re: Never write your own date parsing library

#308

Post by gus_tpm »

popoflojo wrote: post #305
yes_man wrote: post #291

Earlier quoted context omitted.

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

Leap seconds are when it really gets fun.

I will never not be impressed with how well we are able to keep track of time in the world

Re: Never write your own date parsing library

#309

Post by gmueckl »

kulahan wrote: post #297
gmueckl wrote: post #185

Earlier quoted context omitted.

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

I'm not changing any story here. All this "use a library" advice to juniors isn't as universal amd fast as everybody makes it sound. I always find that it sounds too discouraging. There is no magic in these libraries and in their creation - just time and effort. And that's something that needs to be mentioned, too. You can roll your own if you're willing to justify the effort. Depending on the context, it may just not be a good use of your time.

That's why it's also important to point out that no significant piece of code is mature and stable from the start, but was brought into this state iteratively using tools and processes that are available to everybody else, too. The biggest difference between existing mature code and new code under any good development process is age.

Re: Never write your own date parsing library

#310

Post by MichaelRo »

>> I made the very sensible choice to adopt luxon as the Date Parsing library for Eleventy.

Never heard of neither Luxon nor Eleventy but by the ridiculous gay names only I could have bet a million dollars this is yet another instance of the insanity that's Javascript. Honestly, noone outside of the sickening dysfunctional Javascript ecosystem does that, keep rewriting basic crap ad infinitum.

Post reply on HN