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

51–60 of 333 posts

Re: Never write your own date parsing library

#51

Post by PaulHoule »

cyanydeez wrote: post #44
titzer wrote: post #31

Earlier quoted context omitted.

ISO 8601 is the way .

alas, the user doesnt know the way...

That part is easy. Use a date picker of some kind

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

or a text field with some code that converts vernacular dates to a structured format. I don't think users are going to be too weirded out at seeing "1997-04-15" and will probably learn to use that natively.

The hard part is that a lot of devs aren't aware that there's a standard and that standard is superior to the alternatives.

Re: Never write your own date parsing library

#52

Post by devilbunny »

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

Farmers who have to buy things (and that's almost all of them) care about the hours the shops are open, which is affected by DST.

Re: Never write your own date parsing library

#53

Post by 9dev »

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

Re: Never write your own date parsing library

#54

Post by jedberg »

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

Obviously there is a bit of nuance here, but the best rule of thumb is use a regex and then warn the user that it doesn't look valid but still accept it if it doesn't pass, and then send an email to verify it.

Re: Never write your own date parsing library

#55

Post by TheBigSalad »

jimmaswell wrote: post #23

moment is far smaller if you include it without locales you don't need. I don't care how much they talk themselves down on their homepage, begging me to choose a different library - I like it and I'll continue using it. > We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done. > We will not be adding new features or capabilities. > We will not be changing Mo…

I couldn't agree more. I have no idea why the moment devs are trying to kill moment.

Re: Never write your own date parsing library

#56

Post by econ »

indymike wrote: post #20
micromacrofoot wrote: post #7

Multiple times in my career I've had a good laugh when a non-technical manager says something along the lines of "it's just the date, how hard can it be?"

Add phone numbers, email addresses and human names to the list.

Just validate the registration form? Surely this is a solved problem?

Uhhh...

Re: Never write your own date parsing library

#57

Post by habibur »

kccqzy wrote: post #3
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…

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

Re: Never write your own date parsing library

#58

Post by jerf »

3cats-in-a-coat wrote: post #49
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"

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.

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, having established the point that A: the show runners understand this is an issue and B: it makes for a rather tedious watch, they moved on to "everyone speaks English" and we all breathed a sigh of relief. I just think of it as part of the "camera" now. It turns out that we don't necessarily want a truly literal recording of what such things would look like.

[1]: https://tvtropes.org/pmwiki/pmwiki.php/Main/CallARabbitASmee...

Re: Never write your own date parsing library

#59

Post by bluGill »

devilbunny wrote: post #52
TheJoeMan wrote: post #35

Earlier quoted context omitted.

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

Farmers who have to buy things (and that's almost all of them) care about the hours the shops are open, which is affected by DST.

And farmers are annoyed that one day the shop is open just after dawn, and the next not for another hour. Farmers are building their life around sunrise/sunset (or sometimes the dew cycles which is tied to the sun), and then fit the rest of the world in between.

Re: Never write your own date parsing library

#60

Post by jerf »

habibur wrote: post #57
kccqzy wrote: 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.

"Years are not leap years, unless % 4, unless % 100, unless % 400."

It's a wacky rule for sure.

2000 was fun. Everyone knows about "unless % 4", but there was also an interesting and very vocal set of people who knew about the "unless % 100" but somehow knew that without knowing about the "unless % 400" part. A very specific level of knowledge.

Post reply on HN