Nothing came close in quality to Joda-time from Java (later adopted with small fixes as "java.time" built-in). Why not using js-joda port?
Never write your own date parsing library
161–170 of 333 posts
Re: Never write your own date parsing library
#162As for this aside:
> As an aside, this search has made me tempted to ask: do we need to keep Dual publishing packages? I prefer ESM over CJS but maybe just pick one?
Pick ESM. CJS doesn't work in browsers without being transformed to something else. Node can require(esm) now, so it's time to ditch CJS completely.
Re: Never write your own date parsing library
#163I like to use the Japanese calendar as an example to scare the juniors away from DIY parsing: https://learn.microsoft.com/en-us/dotnet/api/system.globaliz... https://learn.microsoft.com/en-us/windows/apps/design/global...
I put these into an ISO8601 parser and it didn't work, I'm going to tell ISO off for obviously DIYing their solution instead of doing the proper thing.
Re: Never write your own date parsing library
#164Earlier quoted context omitted.
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.
Why would I mature yours and deal with those issues when I can just use the already-mature one?
Re: Never write your own date parsing library
#165I ran into date heck recently in a medical setting for storing birthdates. Eventually I settled on the idea that a birthdate isn’t a physical time, it’s just a string. We can force the user to enter it in the format 02/18/1993 leading zeroes and all, and operations on it other than string equality are invalid. We’ll see if this survives contact with the enemy but it’s already going better than storing and reasoning a…
What environment are you in where you have to work with birthdates, you have timezone aware dates, times, and intervals, but you don't have a naive/plain/local date type that already exists forcing you to use strings in place of date-without-timezone? You seem to have a reasonably expedient solution for that problem, but it is surprising to have the combination of things you have to have and things you have to be mis…
They may have something that's just not as easy to work with as strings. E.g. in Swift, you have DateComponents, but that's too dynamic (and Date is sometimes referred to as naive, but that's a misunderstanding, since they are timestamps, not date+time).
Re: Never write your own date parsing library
#166Earlier 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.
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.
Most well-known date library systems have failed in places. Quite a few, still do. So whilst you might get some known regression to test against, nothing can give you a foolproof guide.
You can have reasonable confidence that here there be dragons, but not so much that your assumptions about something will hold.
Re: Never write your own date parsing library
#167When 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.
I write my own, but in production I always use libraries written by some dude from Omaha :)
Re: Never write your own date parsing library
#168Earlier quoted context omitted.
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.
I don't think tables are the hard thing. If you wanted to grow your wood, plane and dry it yourself, etc... then you'd be "hard way" building a table. I assume you use tools?
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.
Re: Never write your own date parsing library
#169When 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…
> I've never met a client
There is difference between “never build your own for a professional need” and “never build your own”.
I build my own stuff if it is for my own purposes, and I use proper tools and libraries for my professional work.
Re: Never write your own date parsing library
#170When 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...
No libraries handle this, though