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

321–330 of 333 posts

Re: Never write your own date parsing library

#321

Post by 1718627440 »

jkingsman wrote: post #158
jgauth wrote: post #123

Earlier quoted context omitted.

"The Hunt for Red October" had an interesting way of handling this with the Russian speakers. The movie starts with them speaking Russian with English subtitles, does a slow zoom into the Russian-speaker's lips, and switches to English mid-sentence.

With some elegance, too; iirc they pivot languages on the word "Golgotha" as he reads from the bible, the Latin word for a location near Jerusalem, but having a non-English/non-Russian word be when they switch made it a lot less jarring. Plus, having it be during a read-out-loud-from-book portion allowed for more measured cadence that smoothed the switch but probably would have felt jarring if the audience were parsi…

> "Golgotha", the latin word

Isn't it Hebrew? (for example see John 19,17)

Re: Never write your own date parsing library

#322

Post by 1718627440 »

TheJoeMan wrote: post #35
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"

It's funny to reason why we must go to bed when the clock has a certain number, since modern technology could easily be programmed to adjust as needed. No technical reasons the Martians can't go to bed at 9:00am today and 9:40am tomorrow. This mirrors my thoughts on why farmers caring about daylight savings time is farcical, farmers I know use the timekeeping of "crack of dawn" and "sunset".

It's a problem, because farmers have contracts with others and need them to do things at 3am one day and 4am on another.

Re: Never write your own date parsing library

#323

Post by 1718627440 »

oneshtein wrote: post #196
hanche wrote: post #46

Earlier quoted context omitted.

Even worse with just two digits for the year! 01/02/03 could be 1 Feb 2003, or 2 Jan 2003, or 3 Feb 2001. Let’s just be thankful no one ever uses any of remaining three permutations.

$ LANG=C date --date="01/02/03" Thu Jan 2 00:00:00 EET 2003 $ LANG=de_AT.utf8 date --date="01/02/03" Do 02 Jän 2003 00:00:00 EET $ LANG=zh_HK.utf8 date --date="01/02/03" 2003年01月02日 星期四 00:00:00 EET

That only shows that date only converts on output and not on input.

Re: Never write your own date parsing library

#324

Post by defrost »

1718627440 wrote: post #321
jkingsman wrote: post #158

Earlier quoted context omitted.

With some elegance, too; iirc they pivot languages on the word "Golgotha" as he reads from the bible, the Latin word for a location near Jerusalem, but having a non-English/non-Russian word be when they switch made it a lot less jarring. Plus, having it be during a read-out-loud-from-book portion allowed for more measured cadence that smoothed the switch but probably would have felt jarring if the audience were parsi…

> "Golgotha", the latin word Isn't it Hebrew? (for example see John 19,17)

From what I have to hand ..

It appeared in the Latin Vulgate (an early predominately Latin version of the Bible), the Oxford English Dictionary has it as an Aramaic form of the Hebrew "gulgōleþ" (copied from the dictionary) or skull like hill.

Re: Never write your own date parsing library

#325

Post by 1718627440 »

shadowgovt wrote: post #97
QuadmasterXLII wrote: post #2

I ran into date heck recently in a medical setting for storing birthdates. Eventually I settled on the idea that a birthdate isn’t a physical time, it’s just a string. We can force the user to enter it in the format 02/18/1993 leading zeroes and all, and operations on it other than string equality are invalid. We’ll see if this survives contact with the enemy but it’s already going better than storing and reasoning a…

IIUC why medical cares at all, this is really insightful. Because as far as I'm aware, the medical industry basically uses birthdate as a key; it helps to (a) tell two patients with other primary keys (like name or address) apart and (b) do a quick mental-acuity check on the patient by just having them regurgitate the value and doing a human-brain string= on it.

The dose varies per age, but this isn't that exact.

Re: Never write your own date parsing library

#326

Post by 1718627440 »

eterm wrote: post #240
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 perio…

> 2000 to 2000 would be a span lasting "1 year"

Yes it is?

Re: Never write your own date parsing library

#327

Post by 1718627440 »

9dev wrote: post #53
jedberg wrote: post #28

Things you should never do: Make your own load balancer software Make firewall software Make a date parsing library Attempt to verify an email with a regular expression.

> Attempt to verify an email with a regular expression. .+@.+ That one always seemed sufficient for me, every issue after that is the users problem

Except email addresses don't need to have an "@".

Re: Never write your own date parsing library

#328

Post by rgavuliak »

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

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

No, people want people that can provide value regardless of the difficulty. What you're describing is how we end up with not invented here syndrome.

Re: Never write your own date parsing library

#329

Post by FigurativeVoid »

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?

Oh it never worked. It was bad design by someone who was well meaning, but inexperienced.

All these issues were resolved, usually, by parsing the date into a proper Date class.

Re: Never write your own date parsing library

#330

Post by SAI_Peregrinus »

hnuser123456 wrote: post #94
whatever1 wrote: post #83

Earlier quoted context omitted.

It’s because it is not systematic historically. It’s a system full of edge cases

It's also a beautiful maze of nerd snipes. There's apparently some shifting going on inside the earth, combining with the slight variability of the moon's distance, which means various days over a month can be more than a millisecond shorter than average. Good luck integrating that into your date.addDays()

The more precisely you try to measure anything the more confounding factors you encounter. Take length as an example: every material has some coefficient of thermal expansion, and that coefficient can itself change with temperature. Even Zerodur. Every material has a finite speed of sound. If you measure length precisely enough and fast enough, you'll find every material changes length as ambient sounds pass through. So everything is a thermometer, and a microphone, and more since there are many other "parasitic" variables.
Post reply on HN