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

231–240 of 333 posts

Re: Never write your own date parsing library

#231

Post by greggyb »

clem wrote: post #61
3cats-in-a-coat wrote: post #49

Earlier quoted context omitted.

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.

Vernor Vinge had it figured out in A Deepness in the Sky with the use of kiloseconds, megaseconds, and gigaseconds.

Coming from an educational background of imperial units, I sometimes catch flak from ... most of the world about this.

I take joy in exuberantly pushing back on their insistence of clinging to such archaic time units as "minutes", "hours", and "days", telling them to come back when they embrace kiloseconds. It is telling that most of my friends accept this with equal joy and laughter (:

It probably doesn't hurt that I've also spent time drilling metric conversions so that I can code-switch pretty seamlessly among units. Neurotic tendencies can have payoffs.

Re: Never write your own date parsing library

#232

Post by kyawzazaw »

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

Corporations and government certainly want people who can execute things that are easy, but reliably and consistently

Re: Never write your own date parsing library

#234

Post by ashoeafoot »

Now i want to make a date format, combined with other data that is the ultimate challenger of date parsing.

IntroDuceThing: The ip:port,date/time,longlat string. Oh, yes its format is also dependant on the language you encode it in and what parts you leave out to be defaulted. .:, is now a valid locationdateip

Re: Never write your own date parsing library

#235

Post by skrebbel »

ceejayoz wrote: post #78
jerf wrote: post #58

Earlier quoted context omitted.

Consider it a translation convention. There's a time and a place for "cycles" or "rels" or whatever, but it gets into "Calling a Rabbit a 'Smeerp'" [1] territory pretty quickly. The payoff isn't really all that great. Stargate SG-1 is one of my favorite instances of this. The first couple of episodes address the fact that the Earth characters do not speak the same languages as everyone else in the galaxy. Then, havin…

> The payoff isn't really all that great. If you’ve read David Weber’s Safehold series, this point gets super clear. It's written with names like "Zherald Ahdymsyn" (Gerald Adamson), but that makes it quite the slog for many.

I could not get through Banks’ “Feersum Endjinn” for this sole reason. English isn't my first language, though I’m fluent in it and read lots of hard sci-fi in it. But half a book using English “spelling rules” applied haphazardly just to make a minor point about one character was well beyond my capacity. I quoted “spelling rules” on purpose because let’s be honest, English doesn’t really have any.

You couldn’t translate that novel to Italian or Finnish, or any language with proper phonetical spelling.

Re: Never write your own date parsing library

#236

Post by mavamaarten »

takinola wrote: post #79

No other programming concept has caused me more grief than dealing with time and timezones. It starts to get really mind-bendingly complex once you start thinking about it deeply. That is even before you start encountering the quirks (some places have timezone changes that depend not only on the time of year but also on the actual year). Lesson learnt - choose a library (moment is great) and never think about time ag…

Especially because 99,9999% of the time I don't even care about any of the special cases, and I just want to show a simple date to a user.

And still, you regularly run into issues, because our API or a third party did something silly

Re: Never write your own date parsing library

#237

Post by rootsu »

dguest wrote: post #33
FigurativeVoid wrote: post #24

I used to work at a company that stored all dates as ints in a YYYYMMDD format. When I asked why, I was told it was so we could subtract 2 dates to get the difference. I asked them why they couldn’t use DATEDIFF since this was in a sql db. They said they hadn’t heard of it and that it must be new.

Wait so one day over the new year is 2025-01-01 - 2024-12-31 = 20250101 - 20241231 = 8870 i.e. 90 months and 10 days or 7 years 6 months and 10 days How is that the same thing as one day?

They might be subtracting taking first 4 digits and the subtracing yyyy-yyyy, mm-mm and dd-dd.

Re: Never write your own date parsing library

#238

Post by kuon »

glibby wrote: post #102
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,…

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.

Hard disagree here. Use it. Of course, if you running code that drive a pacemaker or a train maybe be careful, but in general, do things. We don't want a world where only three old bearded guys can write a compiler or a physic engine. Do the same errors again and you'll learn, eventually you'll do better than those who were here before you.

Re: Never write your own date parsing library

#239

Post by keybored »

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

You can’t convince an employer with that attitude. They’re gonna keep exploiting their employees and “encourage” them to do their “personal development” in their free time.

Re: Never write your own date parsing library

#240

Post by eterm »

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…

> 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 period of 10 years starting with a year divisible by 10 without a remainder.

Decade 1 is year(s) 10 through 19.

Post reply on HN