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

201–210 of 333 posts

Re: Never write your own date parsing library

#201

Post by dylan604 »

ozgrakkurt wrote: post #200

Maybe the title should be “it is difficult to write a date parsing library” “Never write your own x” kind of titles come off as arrogant and demotivating. Maybe some other person will write an excellent date parsing library that will be better than current ones? Maybe they think it is worth to spend some time on it? These kinds of hard things tend to have libraries that are extremely bloated because everyone uses one…

I'll stand by the never roll your own crypto, but never roll your own date parsing library that your DIY crypto library depends would be uber scary

Re: Never write your own date parsing library

#202

Post by dylan604 »

bdangubic wrote: post #167
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.

I write my own, but in production I always use libraries written by some dude from Omaha :)

And that dude is no longer actively maintaining it and you just discovered an issue with it.

Re: Never write your own date parsing library

#203

Post by scbrg »

3cats-in-a-coat wrote: post #49
davidw wrote: post #12

It's like that joke someone posted on Twitter: "I was in favor of space exploration until I realized what it would mean for date/time libraries"

Every time someone mentioned "days" or "months" or "years" in Andor I had to mentally zap my brain not to think about how it doesn't make a sense across a galaxy.

https://starwars.fandom.com/wiki/Galactic_Standard_Calendar#...

The Galactic Standard Calendar or Galactic Standard Time was the standard measurement of time in the galaxy. It was based on the Coruscant solar cycle. The Coruscant solar cycle was 368 days long with a day consisting of 24 standard hours.

60 standard minutes = 1 standard hour

24 standard hours = 1 standard day

5 standard days = 1 standard week

7 standard weeks = 1 standard month

10 standard months + 3 festival weeks + 3 holidays = 368 standard days = 1 standard year

Re: Never write your own date parsing library

#204

Post by oneshtein »

benlivengood wrote: post #144
ceejayoz wrote: post #77

Earlier quoted context omitted.

Seconds are now (in SI) defined as calculated from behavior of cesium-133 atoms. https://en.wikipedia.org/wiki/Caesium_standard

Unfortunately, the Second is measured for purposes of our timekeeping standards at sea-level on Earth which is ~1PPB slower than it would be in free space, as opposed to having a correction factor built into our time standards and so, for example, interplanetary ping times would be slightly shorter (in UTC/TIA nanoseconds) than expected.

A much more precious clock is used by USA to guide nuclear missiles without GPS. (nucleus of Thorium 229 controlled by a high-precision UV laser?)

Re: Never write your own date parsing library

#205

Post by oneshtein »

kccqzy wrote: post #98
habibur wrote: post #57

Earlier quoted context omitted.

> or my favorite January 1, 1600 since 1600 is a multiple of 400 You need to deal with 1600 and 2000 being leap year. While 1700, 1800, 1900 not being a leap year. I limit dates from 1900 to 2100. All !year%4 = leap year. Especially when you try to convert int_date to y,m,d things get tricky.

That's exactly why I propose a multiple of 400, not a multiple of 100. The proleptic Gregorian cycle is a 400-year cycle. There are 97 leap years in it. What's tricky about it? Just take a look at my code: https://github.com/kccqzy/smartcal/blob/9cfddf7e85c2c65aa6de...

Why not just make a map of dates to days since 0001-01-01 in a plain text, then compress it at build time? We are not constrained by memory anymore.

Just use simple database as source of truth with all days passed since a start of human history (e.g. 6000 years ago) with labels such as "this day 12345678 was known as day XXXX-xx-xx in those regions, also known as YYYY-yy-yy in those regions, also known as ZZZZZ in this specific region". It's not a hard task to automatically compress such database into a compact representation.

Re: Never write your own date parsing library

#206

Post by schindlabua »

chii wrote: post #197
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,…

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

Except making employers do only easy things will make them stagnate. People who do nothing but simple CRUD apps over and over won't even be particularly good at making CRUD apps... whereas the guy who builds an Unicode font renderer in his free time always seems to write better code for some reason.

Getting better at your job is not just a "personal want" but very much something that the employer appreciates aswell.

Of course reinventing the wheel isn't good in corporate because the reinvented wheel is buggier than the ready made npm package but employers should go out of their way to find hard problems to solve that they can pass to their employees. It's called a growth opportunity.

Re: Never write your own date parsing library

#207

Post by aussieguy1234 »

Almost never...

There may be some obscure cases.

Like for example, lets say you are writing very performance sensitive code where nanoseconds count. All of the date parsing libraries available for the language you are writing are too slow for your requirements. So you might roll your own lighter weight faster one.

Re: Never write your own date parsing library

#208

Post by Animats »

I requested an ISO 8601 date parser in the Python "datetime" library in 2012.[1] "datetime" could format into ISO 8601, but not parse strings. There were five ISO 8601 parsers available, all bad. After six years of bikeshedding, it was was fixed in 2018.

That's what it took to not write my own date parsing library.

[1] https://github.com/python/cpython/issues/60077

Re: Never write your own date parsing library

#209

Post by psychoslave »

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

There are different kind of hardship though.

There things which was a result will make your mind click to an other way to comprehend a problem space and how to navigate through it.

And there are things which are hard due to pure accumulation of concurrent conventions, because of reasons like coordinating the whole humanity toward harmony with full happy peaceful agreement of everyone is tricky.

Handling date is rather the latter. If you dig in the lucky direction, you might also fall into cosmological consideration which is a rabbit hole of its own, but basically that's it: calendars are a mess.

Re: Never write your own date parsing library

#210

Post by motorest »

Animats wrote: post #208

I requested an ISO 8601 date parser in the Python "datetime" library in 2012.[1] "datetime" could format into ISO 8601, but not parse strings. There were five ISO 8601 parsers available, all bad. After six years of bikeshedding, it was was fixed in 2018. That's what it took to not write my own date parsing library. [1] https://github.com/python/cpython/issues/60077

> That's what it took to not write my own date parsing library.

If you wrote your own date parsing library, there would be six ISO 8601 parsers available, all bad.

You should feel grateful for not having wasted your time.

Post reply on HN