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

211–220 of 333 posts

Re: Never write your own date parsing library

#211

Post by ahf8Aithaex7Nai »

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…

> 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 company. Unfortunately, I often see employees doing things quite badly that they don't really understand because they are not given the opportunity to learn properly. I can't imagine that this burns less money in the medium and long term than giving paid employees adequate space to learn.

Re: Never write your own date parsing library

#212

Post by xaer »

I wrote the ethlo ITU library because I was annoyed with the lack of performance and large amount of ceremony to parse and format standard timestamps in RFC-3339 format in Java. It is somewhat more extensive now, and is used in other libraries. Ask me anything!

Re: Never write your own date parsing library

#213

Post by quelsolaar »

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…

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

Re: Never write your own date parsing library

#214

Post by motorest »

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

> People say that about hard things, and I only want to do hard things.

That's perfectly fine. Your time, your hobbies.

> Nobody wants people who can do easy things, people want people who can do hard things.

No, not really. People want people who do easy things, because they are clever enough to avoid needlessly wasting their time having to do hard things when they could have easily avoided it.

It's your blend of foolish mindset that brought us so many accidental complexity and overdue projects. There's a saying: working smart instead of working hard.

> 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 cut it out, this isn't LinkedIn.

Re: Never write your own date parsing library

#215

Post by tobyhinloopen »

fsckboy wrote: post #192

> Consider "200". Is this the year 200? Is this the 200th day of the current year? Surprise, in ISO 8601 it’s neither — it’s a decade, spanning from the year 2000 to the year 2010. And "20" is the century from the year 2000 to the year 2100. there is so much wrong with this paragraph, it's a nest of people who shouldn't work on date parsing. there is no way 200 is any kind of date, but if you're going to insist it is…

I agree, "200" is just "NotADate". I like JS-Joda's date formatting.

Re: Never write your own date parsing library

#216

Post by motorest »

quelsolaar wrote: post #213
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…

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?

Re: Never write your own date parsing library

#217

Post by quelsolaar »

leakycap wrote: post #103
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 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…

Writing in binary or cranking your own electricity is easy. Anyone can do it.

There is a difference between things that are difficult and things that just take a lot of work.

Re: Never write your own date parsing library

#219

Post by pletnes »

ahf8Aithaex7Nai wrote: post #211
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…

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

Re: Never write your own date parsing library

#220

Post by jillesvangurp »

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 commonly used variants of it and gets rid of all the ambiguity.

For me, timestamps following this pattern 'YYYY-MM-DDThh:mm:ss.xxxxxZ' is all that I use and all my APIs will accept/produce. It's nice that other legacy systems are available that don't normalize their timestamps to UTC for whatever reason, that consider seconds and fractions of a second optional, etc. But for unambiguous timestamps, all I want is this. It's fairly easy to write a parser for it. A simple regular expression will do the job. Of course add unit tests. Technically the Z is redundant information if we can all agree to normalize to UTC. Which IMHO we should. In the same way the T part and separators are redundant too. But they are nice for human readability.

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.

It's only when you get into supporting all the pointless and highly ambiguous but valid variants of ISO 8601 that parsing becomes a problem. There's actually no such thing as a parser that can parse all valid variants with no knowledge of which variant is being used. There are lots of libraries with complex APIs that support some or all of the major and minor variants of course. But not with just one function called parse().

I think the main challenge with ISO 8601 is that it never called out this variant as a separate thing that you should be using. This really should be its own standard. And not using that would be a mistake. ISO 8601 is what happens when you do design by committee.

Post reply on HN