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

251–260 of 333 posts

Re: Never write your own date parsing library

#251

Post by UltraSane »

oneshtein wrote: post #204
benlivengood wrote: post #144

Earlier quoted context omitted.

Unfortunately, the Second is measured for purposes of our timekeeping standards at sea-level on Earth which is ~1PPB slower than it would be in free space, as opposed to having a correction factor built into our time standards and so, for example, interplanetary ping times would be slightly shorter (in UTC/TIA nanoseconds) than expected.

A much more precious clock is used by USA to guide nuclear missiles without GPS. (nucleus of Thorium 229 controlled by a high-precision UV laser?)

That clock hasn't actually been built yet and it wouldn't be useful for guiding nuclear missiles.

https://en.wikipedia.org/wiki/Nuclear_clock

Re: Never write your own date parsing library

#253

Post by patrick0d »

kuon wrote: post #238
glibby wrote: post #102

Earlier quoted context omitted.

By all means, write it. Just don't use it. These warnings are almost always in the context of code you're going to release, not exercises in learning on your own.

Hard disagree here. Use it. Of course, if you running code that drive a pacemaker or a train maybe be careful, but in general, do things. We don't want a world where only three old bearded guys can write a compiler or a physic engine. Do the same errors again and you'll learn, eventually you'll do better than those who were here before you.

Well don't do it and instead of using an off the shelf library that is known to work while the rest of the development team isn't reinventing the wheel. Doing it for fun and education is fine of course.

Re: Never write your own date parsing library

#254

Post by sabas123 »

kuon wrote: post #238
glibby wrote: post #102

Earlier quoted context omitted.

By all means, write it. Just don't use it. These warnings are almost always in the context of code you're going to release, not exercises in learning on your own.

Hard disagree here. Use it. Of course, if you running code that drive a pacemaker or a train maybe be careful, but in general, do things. We don't want a world where only three old bearded guys can write a compiler or a physic engine. Do the same errors again and you'll learn, eventually you'll do better than those who were here before you.

> We don't want a world where only three old bearded guys can write a compiler or a physic engine.

Don't write your own OS does not mean do not contribute to something like the linux kernel.

Re: Never write your own date parsing library

#255

Post by stevage »

jgauth wrote: post #123
jerf wrote: post #58

Earlier quoted context omitted.

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

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

I found that incredibly clunky when I saw it. Also, it's a little bit extra jarring that Sean Connery goes from speaking Russian to speaking English with a Scottish accent.

Re: Never write your own date parsing library

#256

Post by cmdlyne2 »

glibby wrote: post #102
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,…

By all means, write it. Just don't use it. These warnings are almost always in the context of code you're going to release, not exercises in learning on your own.

> By all means, write it. Just don't use it.

I'd say write it, probably don't use it, and don't share it unless it's substantially better than the alternative.

This way, you'll learn about it, but you'll more likely stay with something standard that everyone else is using, and you don't share yet another library that wastes others' time and your own (having to read about it, evaluate it, use it, and the migrate off of it when it's abandoned).

Re: Never write your own date parsing library

#257

Post by skrebbel »

ttiurani wrote: post #249
jillesvangurp wrote: post #245

Earlier quoted context omitted.

> Frankfurt on July 26th 2029 at 1pm That's a localized date and time. And it shouldn't be what you store but what you present based on the user's preferences. The same calendar event would be completely different in the calendar of a tourist visiting Frankfurt. And calendar invites of course can have multiple participants that each want their date times localized to their time zone and locale. So the best way to do…

> That's a localized date and time. Note that I'm not arguing against storing the numeric part in a consistent format, of course you should. My point is that right mow in 2025 you don't know the timezone. E.g. if you write that as the zones are now, it would be "2029-07-26T11:00:00.000Z", but if the timezones change, then when a person is looking at their calendar in 2029, they will be an hour early or late to the me…

I agree with the gist of your comment but I think you’re using the wrong words.

A time zone, as the name implies, is a zone, a place. The most common way to indicate a timezone is a continent+city combo that is both politically and geographically close, so it’s unlikely to change. Therefore, I very much know the timezone of Frankfurt, both today and in the reasonably close future, namely “Europe/Berlin”.

You’re talking about the timezone offset. You’re right, don’t store that for future local dates. Store the timezone.

(Or just the exact location, but then you need a way to map location -> offset if you ever want to do time math on it, and the IANA Continent/City format strikes a nice pragmatic balance there)

Re: Never write your own date parsing library

#258

Post by yas_hmaheshwari »

deepsun wrote: post #161

Nothing came close in quality to Joda-time from Java (later adopted with small fixes as "java.time" built-in). Why not using js-joda port?

I never knew that js-joda existed. I love Joda library.

Its surprising that date / time parsing is screwed in multiple languages

Re: Never write your own date parsing library

#259

Post by Arrowmaster »

ttiurani wrote: post #249
jillesvangurp wrote: post #245

Earlier quoted context omitted.

> Frankfurt on July 26th 2029 at 1pm That's a localized date and time. And it shouldn't be what you store but what you present based on the user's preferences. The same calendar event would be completely different in the calendar of a tourist visiting Frankfurt. And calendar invites of course can have multiple participants that each want their date times localized to their time zone and locale. So the best way to do…

> That's a localized date and time. Note that I'm not arguing against storing the numeric part in a consistent format, of course you should. My point is that right mow in 2025 you don't know the timezone. E.g. if you write that as the zones are now, it would be "2029-07-26T11:00:00.000Z", but if the timezones change, then when a person is looking at their calendar in 2029, they will be an hour early or late to the me…

Ah I have the perfect solution. Let's add GPS coordinates to datetime stamps!

Please put the pitchfork away it was only a joke. (Until someone actually does this because it makes a twisted sort of sense)

Re: Never write your own date parsing library

#260

Post by zelphirkalt »

mattmanser wrote: post #118
ramijames wrote: post #109

Earlier quoted context omitted.

This is such nonsense. All the stuff that we use, someone wrote. If nobody makes them, then how is that going to work? The messaging here is that you should be careful about using what you build on your own because it: - hasn't been battle tested - likely has bugs - isn't mature The only way that it will be all of those things is if someone invests time and energy in them. From an ecosystem perspective this is absolu…

It's about exposure. The things that people write that everyone uses have had HUGE exposure. They've been exposed to all the edge cases, they've been tested millions, if not billions of times. All the bugs ironed out. The people who've worked on them are now the greatest domain experts on that little corner of comp-sci. Yours won't unless it hits prime time. So yours will be weak, brittle and dangerous.

This assumes, that the practices/methods used to create a working library are suitable for solving the problems. They might be ill-advised and include tons of workarounds for bad design decisions. Too often following the advice of never reinventing anything (and possibly doing better), is how we ended up with stacking broken stuff on top of other broken stuff, limiting us at every turn with leaking abstractions and bad designs.

It is very possible to have a clean implementation with good design choices overtake an established in time, enabling more extensibility, modularity and maintainability.

An example: People still way over-use regexes for all kinds of stuff. Even in code editors people for syntax recognition, where people really should know better.

Post reply on HN