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

281–290 of 333 posts

Re: Never write your own date parsing library

#281

Post by GoblinSlayer »

ttiurani wrote: post #274
skrebbel wrote: post #257

Earlier quoted context omitted.

I agree with the gist of your comment but I think you’re using the wrong words. A time zone, as the name implies, is a zone, a place. The most common way to indicate a timezone is a continent+city combo that is both politically and geographically close, so it’s unlikely to change. Therefore, I very much know the timezone of Frankfurt, both today and in the reasonably close future, namely “Europe/Berlin”. You’re talki…

Well, not really. :) Timezones are the whole area that has the same time. So "Europe/Berlin" and "Europe/Rome" right now can be used in user-facing help texts to make the timezone understandable, but those cities might not be in the help text in the future. That's because: "Each time zone is defined by a standard offset from Coordinated Universal Time (UTC)." ( https://en.m.wikipedia.org/wiki/Time_zone ) So the offse…

Or in 2027 the Sith Empire could conquer Earth and install imperial time system. Good luck with your timestamps. Just make your scheduler as a walled garden SaaS - no need to exchange timestamps.

Re: Never write your own date parsing library

#282

Post by mikepurvis »

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 extracted, it's just special cases and arbitrary parameters all the way down.

I'm up for a challenge of course, but all else being equal, I'm happy to leave work that is the "bad hard" to others.

Re: Never write your own date parsing library

#284

Post by nicoburns »

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

> So go ahead, write your own date library, your own Unicode font rendering, compiler, OS, game engine or what ever else people tell you to never do because its hard.

You can absolutely do these things. What you need to be aware of is that in most cases maintaining these things to a production quality level is full-time job for a talented engineer. So you shouldn't attempt these IF:

- You have a higher-level aim you are also trying to achieve

- You need a production quality implementation

If one of those isn't the case then knock yourself out.

Re: Never write your own date parsing library

#285

Post by cobertos »

> Most date parsing woes (in my opinion) come from ambiguity: from supporting too many formats or attempting maximum flexibility in parsing. ... There is a maintenance freedom and simplicity in strict parsing requirements ...

Is this the endgame of "be liberal in what you accept, but strict in what you output"? You end up supporting an untold amount of usage patterns, not even chosen by yourself if you use a library like `luxon` to handle the "be liberal" part for you.

Re: Never write your own date parsing library

#286

Post by bapak »

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…

Correct. It's not hard, just stupidly time consuming to the point of being unable to ever produce anything that works 70% of the time.

I hate anyone who will attempt to craft their own 10-lines line parser and then ignore that it fails 4 times a day. Just use the damn library. Thank you.

Write it for fun, but don't ship it. You're wasting everyone's time with your craft.

Re: Never write your own date parsing library

#287

Post by kaoD »

geocar wrote: post #198
kaoD wrote: post #36

Earlier quoted context omitted.

I like how Temporal[0] does this. What you were dealing with is Temporal.PlainDate[1], i.e. 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). Temporal has other cool types, each with distinct semantics: - 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 acr…

> 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 summary: most of your concerns are wrong due to (1) confusing "timezones" with "location" or "internationalization" (2) confusing internal representations (like Epochs) with what these objects represent as described in the "important concepts" link and (3) just being completely wrong like saying you cannot do reasonable arithmetic with PlainMonthDay or even understand that not every relevant operation is arithmetic (good luck calling `.toPlainDate(2025)` with your string representation).

Re: Never write your own date parsing library

#288

Post by myaccountonhn »

avanwyk wrote: post #139
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 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.

I think it's a spectrum and most fall somewhere on the line, hopefully dependent on the project.

My personal limit is rolling my own crypto, but I'm definitely more on the DIY scale because I agree. It's a fantastic way to grow and learn, and it's likely you might not have the energy to do it outside of work.

Re: Never write your own date parsing library

#289

Post by DonHopkins »

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

It's so tempting to tell you "never implement your own html parser using regular expressions" just to make you do it.

I triple dog dare you!

https://www.youtube.com/watch?v=mc6pk2FRhbA

Re: Never write your own date parsing library

#290

Post by eterm »

fsckboy wrote: post #276
eterm wrote: post #240

Earlier quoted context omitted.

> 2000 to 2010 is 11 years This is obviously wrong by induction. If 2000 to 2010 is 11 years, then: 2000 to 2009 would be length 10 years ... 2000 to 2001 would have length 2 years and finally 2000 to 2000 would be a span lasting "1 year". But any span with the same start and end point must have length zero, it's nonsensical to have a system without that property. As for the spec, ISO 8601 defines a decade as a perio…

> any span with the same start and end point must have length zero "a year" is not a point, it's a span. so is a decade. > Decade 1 is year(s) 10 through 19 but the property you are trying to describe goes hand in hand with 0-based indexing, and thus we see that ISO Decade 0 is >sad tuba< 9 years long

It is actually 10 years long by how ISO 8601 defines a decade.

Also it's worth noting here that ISO 8601 has a year zero, which equates to 1BC in historical terms.

Post reply on HN