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

191–200 of 333 posts

Re: Never write your own date parsing library

#191

Post by mystifyingpoi »

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.

Well, in entirety of SW (or at least in mainline movies) it is kinda strange, that day and night happens basically on the same 24h period as on our Earth, given that all the planets are different. Could make a much more interesting story without this crutch for the audience.

Re: Never write your own date parsing library

#192

Post by fsckboy »

>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 unless "to" means "up to but not including" in which case it should say 2001 to 2011 if you want to refer to the 200th decade, since decade 1 was 1AD through 10AD...

there is no saving this post

Re: Never write your own date parsing library

#193

Post by geocar »

dracodoc wrote: post #149
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,…

It's not because it's "hard". It's all about the nuisance created by human behavior. Calendar, DST, timezone, all the problems you never imagined can happen and can only be met in real life scenarios, and you will meet same problem again, struggle then found out the same problem have been solved long time ago by mature library, and the solution doesn't require any smart or advanced technique, just another corner case…

I disagree hard.

Firstly because I have a great imagination, but secondly because I am old and have a lot of real life scenarios to think about.

State-of-the-art here has changed a few times in my professional career: Once upon a time most time/date libraries used a single integral type and try to make it do double-duty by being both interval and absolute (whatever that means) time by taking the interval from an epoch.

Relatively recently however, that's started to change, and that change has been made possible by people using languages with better type systems reinventing the date/time approach. This has led to fewer bugs, and more predictability with regards to calendar operations in different programs.

But bugs still happen, so this approach is still unsatisfying. One thing I keep having to worry about is distance; I record RTT as part of my events, since when I am looking for contemporaneous events, the speed-of-light actually tends to be a real factor for me.

So I don't think this is solved simply because my problems aren't solved by existing libraries, and I keep getting into arguments with people who think GMT=TAI or something dumb like that.

It's not "all about" anything: Nobody knows shit about what's happening in the next room over, and if there are 12 different date/time libraries now, I guarantee there'll be a 13th that solves problems in all of them, and is still incomplete.

Re: Never write your own date parsing library

#194

Post by nwallin »

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…

> they pivot languages on the word "Golgotha"

"Armageddon" actually. Poignant because it's a movie about a nuclear ballistic submarine. But not a particularly non-English word.

Re: Never write your own date parsing library

#195

Post by ozim »

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

Missing context is - there is always something else you work on like the guy was making Eleventy so it was waste of his time.

If you work for a company and build todo app most likely it will not be beneficial for you to implement in-house library because there will be stuff that will bring much more value.

Like you don't have now 2 years to cover for all hard stuff because you have to make synchronization of tasks between devices and your boss most likely won't appreciate that.

"Never roll your own cryptography" is always used in context of building another application it is never "don't become a cryptography specialist".

Re: Never write your own date parsing library

#196

Post by oneshtein »

hanche wrote: post #46
senfiaj wrote: post #25

Earlier quoted context omitted.

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.

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

Re: Never write your own date parsing library

#197

Post by chii »

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

> 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 purposes - which is fine and i encourage people to do it, on their own dime. Like climbing Mount Everest, or going to the south pole.

But if you are doing a project for someone else, you don't get to piggy back your personal wants and desires unrelated to the project on to it.

Re: Never write your own date parsing library

#198

Post by geocar »

kaoD wrote: post #36
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…

I like how Temporal[0] does this. What you were dealing with is Temporal.PlainDate[1], i.e. a date with a calendar associated but no time or timezone (might be due to being implied but also might be irrelevant, like in birthdates). Temporal has other cool types, each with distinct semantics: - Instant: a fixed point in time with no calendar or location. Think e.g. "the user logged in at X date and time" but valid acr…

> a date with a calendar associated but no time or timezone (might be due to being implied but also might be irrelevant, like in birthdates).

It might also be relevant: Ever ask an older Korean person their age?

> Instant: a fixed point in time with no calendar or location. Think e.g. "the user logged in at X date and time" but valid across the world for any timezone or calendar system. This is what we usually use "Unix UTC timestamps" for.

This is not a thing. Those are intervals to some Epoch, maybe taking into account leap-seconds and maybe not. They are not very useful except grossly over long ranges.

> - ZonedDateTime: like an Instant but associated with a particular calendar and location. Think an Instant but rendered "real" into a calendar system and timezone so the user can see a meaningful time for them.

Like when a user logged in at X date and time. They don't do this from no location, but from some location.

> - PlainDate: already discussed. Think e.g. birthdates.

And already wrong.

> - PlainTime: think "run task every day at 6:30pm".

Erm no. You can say 18:30 hours after midnight, or you can say when the calendar says 6:30pm, but these are different things. Imagine the poor fool who wants to run the task every day at "1:30am" and has it run twice on some days.

Bars close in some parts of the world at 30h (30時) to mean 6am the following day.

> - PlainDateTime: like an Instant but associated with a calendar system, but no timezone. Think e.g. what a user would insert in a datetime picker, where the timezone is implied instead of explicitly selected.

No, like a string.

> - PlainYearMonth: think e.g. "we'll run our reports during October 2025".

Nonsense. Also a string.

> - PlainMonthDay: think e.g. "my birthday is June 13".

Your birthday might be on the 29th of January. You cannot do reasonable arithmetic with such things, so it might as well be a string like many of these others.

> I like how Temporal[0] does this.

I don't if you can't tell. This stuff is complicated and I'd like more people exploring it because I don't know The Right Answer™ either, but I know enough to know that every existing solution is wrong in some way that can cause real harm.

Re: Never write your own date parsing library

#199

Post by BurningFrog »

layer8 wrote: post #71
BurningFrog wrote: post #67

Earlier quoted context omitted.

A second is still originally defined as 1/86400 of an Earth day. That doesn't make it unusable as a cross galactic time unit, and I think the same goes for years and hours.

The issue is that planetary locales will each have their own days and years (and possibly hours), so it would be confusing to adopt that same nomenclature for an interplanetary/interstellar time unit. And since the latter will be inconsistent with local time systems anyway, it’s easier to just have it use powers of ten. At least until we meet aliens that may prefer a different base.

I was 100% thinking of use by humans living on other worlds. Pretty sure Mars will use seconds and hours. Handling dates will awkward whatever they decide on.

Currently, a Mars days is called "sol", FWIW.

If we find other species out there I won't speculate on how they think about time.

Re: Never write your own date parsing library

#200

Post by ozgrakkurt »

Maybe the title should be “it is difficult to write a date parsing library”

“Never write your own x” kind of titles come off as arrogant and demotivating.

Maybe some other person will write an excellent date parsing library that will be better than current ones? Maybe they think it is worth to spend some time on it?

These kinds of hard things tend to have libraries that are extremely bloated because everyone uses one library, and that one library has to work for everyone’s use case.

You can see this in the post too, not everyone needs to be able to parse every single date format.

Post reply on HN