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

221–230 of 333 posts

Re: Never write your own date parsing library

#221

Post by d_tr »

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

In a scenario where a programmer has to do this for work and might naively think that date handling is simple, the title is invaluable advice. It is one of those things that can cause real trouble.

OTOH writing, e.g., your own renderer could cause some funny display at worst and maybe some unnecessary effort.

Re: Never write your own date parsing library

#222

Post by pjmlp »

schindlabua wrote: post #206
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…

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

Unless you work for enterprise consulting where employers appreciate replaceable cogs that they randomly drop into any project, and nicely out project budget regardless of delivery quality.

Re: Never write your own date parsing library

#223

Post by pjmlp »

pletnes wrote: post #219
ahf8Aithaex7Nai wrote: post #211

Earlier quoted context omitted.

> and i don't want to pay my employees to learn, i want to pay them to produce output i can sell. This can be a bad local optimum. It probably depends on what exactly your business does, but it can make sense to pay an employee to acquire knowledge and skills that are needed in the business. You can't buy this off the shelf in all circumstances. Of course, it also has to make economic sense and be viable for the comp…

Also as an employee, this forces me to job hop to stay relevant.

Unless you happen to live in cultures where that is looked down upon as not able to keep a job.

Re: Never write your own date parsing library

#224

Post by d_tr »

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…

I am in a work environment where I actually get to do hard shit for fun, learn a ton, and also "get stuff done" and my employer is happy.

For some of the stuff that has been done already, it might still make sense to do your own implementation, for example if you want to be able to experiment without having to navigate and learn a huge codebase and then have to maintain a fork just to have your own stuff in.

Another project we are starting now involves replacing software which is outright crappy and wastes our time. Thankfully my employer was able to see and understand this after talking it through with them.

Re: Never write your own date parsing library

#226

Post by bdhcuidbebe »

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…

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

Re: Never write your own date parsing library

#227

Post by rambambram »

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…

Is quelsolaar your employee?

Re: Never write your own date parsing library

#228

Post by bdhcuidbebe »

motorest wrote: post #216
quelsolaar wrote: post #213

Earlier quoted context omitted.

Your customers will pay more for things that are hard to do. Ask ASML.

> Your customers will pay more for things that are hard to do. Ask ASML. What a silly example. ASML is valuable because it does something no one else does. It's not because it's hard, it's because they have the know-how and infrastructure to do it whereas others don't. Juggling is hard. Do you know any millionaire jugglers?

> Juggling is hard.

You should try instead.

I brought jugglers balls for my team and in a few weeks we had 4 or 5 fluent.

Re: Never write your own date parsing library

#229

Post by cookiengineer »

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 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 specific Month in numbered form like say "YYYY-03-01 to YYYY-10-01", they literally wrote the law quoting "first Sunday of April" to "last Sunday in October". Before 2007 it was "Second Sunday in March" to "first Sunday in November".

I'm not making this shit up, go ahead and read the law, come back and realize it's even more complex for other timezones, because some nations seem to make fun of this by going to +14:00 hours and -11:30 hours depending on the president's mood on Christmas or something.

In order to find out the Day of a specific calendar date, there's this cool article about Determination of the day of the week [1] which is quite insane on its own already. There is no failsafe algorithm to do that, each method of determining the day of the week has its own tradeoffs (and computational complexity that is implied).

Then you need to get all Sundays of a month, count the right one depending on the year, map back the date to ISO8601 and then you know whether or not this was daylight saving time they're talking about. Also make sure you use the correct local time to shift the time, because that changed too in the law (from 02:00LST to 03:00LDT and 02:00 LDT to 01:00LST before, to 02:00LST to 03:00LDT and 02:00LDT to 01:00LST after the changes).

Took me over 4 fvcking weeks to implement this in Go (due to lack of parsers), and I hate Amazon for this to this date.

PS: Write your own Datetime parser, this will help you realize how psychotic the human species is when it comes to "standards". After all this I'm in huge favor of the Moon Phase based International Fixed Calendar [2]

[1] https://en.wikipedia.org/wiki/Determination_of_the_day_of_th...

[2] https://en.wikipedia.org/wiki/International_Fixed_Calendar

Re: Never write your own date parsing library

#230

Post by ttiurani »

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

But if your unlucky enough to need to handle future dates, especially "clock on the wall" ("let's meet in Frankfurt on July 26th 2029 at 1pm"), then you just can't know the timezone. The reasons can be many political ones, but especially in this case there's a high probability that EU will remove daylight saving time by then.

So in those cases, if you want to be correct, you'd need to include the geolocation in the stored timestamp.

Post reply on HN