Live data from Hacker News

Never write your own date parsing library

zachleat.com

91–100 of 333 posts

Re: Never write your own date parsing library

#91

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

9,192,631,770 is clearly a sensible number and not something that's blatantly chosen to match some arbitrary pre-existing geocentric standard like 10,000,000,000 would have been.

It's retrofitted to what we already defined as a second, sure.

But you can tell an alien species our units are expressed in multiples of that, and they can translate it into how theirs works. (Vinge, for example, has space-faring humans talk about "megaseconds" and "gigaseconds" rather than days/years.)

Re: Never write your own date parsing library

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

Is parsing HTML with regexes Ok?

No. See https://stackoverflow.com/questions/1732348/regex-match-open...

Re: Never write your own date parsing library

#93
post #69

Earlier quoted context omitted.

Case-in-point, you are mistaken. The duration of a day changes due to many things, both logically and also physically due to the nature of Earth. Also just because you can call a second a second doesn't mean that is helpful making datetime software usable or easy on a different planet.

I think he's speaking historically. Obviously now a second is a fundamental SI unit defined in terms of physics experiments, but the origin of it was as the amount of time that was 1/3600th of an hour of which there are 24 in the day.

Similar to how almost-pi-squared meters-per-second shows up in the constant for gravitational acceleration near Earth's surface because the meter was originally "the length of pendulum that ticks once a second" and there's a pi in the pendulum motion equation.

(... it's not exactly pi-squared because the French yanked it around a bit before settling into the modern number based on light in a vacuum and cesium atoms).

Re: Never write your own date parsing library

#94

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…

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

Re: Never write your own date parsing library

#95

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…

The really important thing to remember about timezones is they're not a mathematical construct, or a physics construct, or an astronomy construct... They're a political construct. Framed in that light, they have every bit the complexity of having some piece of your code depend on the law (except it's the law of every nation you expect to be running your code in).

Re: Never write your own date parsing library

#96
post #3

Earlier quoted context omitted.

> people’s birthdays changing when they move timezones That's because the developers use datetimes (aka timestamps) to store a single date. Just pick an arbitrary epoch date (such as January 1, 1900 as used by Excel, or my favorite January 1, 1600 since 1600 is a multiple of 400 making leap year calculations even simpler) and store the number of days elapsed since then. The rules involving leap years are much much si…

> The translation from/to this representation to a broken-down y/m/d takes only ~50 lines of code anyways. Didn't the article explicitly tell us not to write our own date parsing library?

I disagree with that. And furthermore it's not parsing. It's converting between a single integer and a tuple of three integers.

Re: Never write your own date parsing library

#97

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.

Re: Never write your own date parsing library

#98
post #57
post #3

Earlier quoted context omitted.

> people’s birthdays changing when they move timezones That's because the developers use datetimes (aka timestamps) to store a single date. Just pick an arbitrary epoch date (such as January 1, 1900 as used by Excel, or my favorite January 1, 1600 since 1600 is a multiple of 400 making leap year calculations even simpler) and store the number of days elapsed since then. The rules involving leap years are much much si…

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

Re: Never write your own date parsing library

#99
post #27

I like to use the Japanese calendar as an example to scare the juniors away from DIY parsing: https://learn.microsoft.com/en-us/dotnet/api/system.globaliz... https://learn.microsoft.com/en-us/windows/apps/design/global...

Do your users type in such dates? No? Problem solved.

The benefit of DIY parsing is to make the problem simple by restricting it to the set of plausible inputs your users will want your code to handle, not to make a highly general library. The right takeaway for juniors is to stop over-complicating things.

Re: Never write your own date parsing library

#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, OS, game engine or what ever else people tell you to never do because its hard.

Post reply on HN