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

21–30 of 333 posts

Re: Never write your own date parsing library

#21

Post by happytoexplain »

8organicbits wrote: post #6
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…

> in the format 02/18/1993 Is this DD/MM/YYYY or MM/DD/YYYY? I can tell from the 18 that it's the latter, but that convention isn't universal. I'd recommend YYYY/MM/DD as a less ambiguous format, but I don't have a perfect answer.

This isn't really relevant to the parent's topic though, aside from UX. The UI can tell the user which is the day and which is the month. The logic layer knows the format explicitly.

Re: Never write your own date parsing library

#22

Post by mattkrause »

_mlbt wrote: post #5
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…

Even better, just make the user input dates using a calendar date picker widget instead of a text field. This gives you full control of the input.

I always find that a little annoying: it takes way too many clicks (esp. for a birth year) and then you've got to find the day of the week.

I'd hate it less if typing updated the widget.

Re: Never write your own date parsing library

#23

Post by jimmaswell »

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 Moment's API to be immutable.

> We will not be addressing tree shaking or bundle size issues.

> We will not be making any major changes (no version 3).

> We may choose to not fix bugs or behavioral quirks, especially if they are long-standing known issues.

I consider this a strength, not a weakness. I love a library that's "done" so I can just learn it once and not deal with frivolous breaking changes later. Extra bonus that they plan to continue making appropriate maintenance:

> We will address critical security concerns as they arise.

> We will release data updates for Moment-Timezone following IANA time zone database releases.

Re: Never write your own date parsing library

#24

Post by FigurativeVoid »

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.

Re: Never write your own date parsing library

#25

Post by senfiaj »

8organicbits wrote: post #6
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…

> in the format 02/18/1993 Is this DD/MM/YYYY or MM/DD/YYYY? I can tell from the 18 that it's the latter, but that convention isn't universal. I'd recommend YYYY/MM/DD as a less ambiguous format, but I don't have a perfect answer.

Every time I see an input date string in XX/XX/YYYY format I get a micro PTSD flashback. This cannot be parsed reliably and is locale dependent. The standard date format is YYYY-MM-DD (it's also the date part of the ISO time format). Raw text inputs should be avoided as much as possible, date/time pickers should be preferred.

Re: Never write your own date parsing library

#30

Post by jimmaswell »

the__alchemist wrote: post #15

Good general rule of thumb, but desperate scenarios call for desperate measures. I would never do this in Python or Rust for example, but it's necessary in Javascript; `Date` and `Moment`, are so full of traps that the ends justify the means: Especially if you have use for a `Date` or `Time` type.

moment's given me no trouble at all. I certainly haven't found it to be full of traps. Addressing the most common complaint: a moment object is mutable, sure - that's a valid design choice, not a trap. Follow the docs and everything works perfectly well IME.
Post reply on HN