The table of listed date formats doesn't look too difficult to implement. A quick look at the RFC tells me, that the RFC even specifies a grammar, though very incomplete. It would be prudent to specify a complete grammar in the RFC of course. Then it would be even simpler taking that grammar and translating it to whatever library one uses for describing grammars for parsing stuff. I really hope all these libraries didn't make silly things with regexes ...
Never write your own date parsing library
261–270 of 333 posts
Re: Never write your own date parsing library
#262Earlier 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.
It's interesting that people are disagreeing with you in a way that they're making it sound like they're elaborating on your point.
To the people reading this, please don't just disagree with an "obvious counterexample". Explain why!
Re: Never write your own date parsing library
#263When 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,…
> When ever i see "never implement your own...", i know i want to implement it myself.
Doing stuff for learning is useful, and the intent behind this general phrase is to not ‘implement your own’ something which is both hard and critical in a production environment. I work in cryptography (for security purposes) and have implemented quite a few things myself to learn, but I still use stable, field tested, and scrutinized crypto for any actual use.
> 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.
Only wanting to do hard things limits yourself quite a bit: what about things which seem easy but could be improved? I worked in a non-tech related medical manufacturing job for a bit and took time to learn the process and tools. Afterward, I implemented a few tools (using what my coworkers (who have no programming or IT experience) have available to them: Excel and the VBA on the lab computers) to help them prep inventory lists which they have been doing by hand. Doing it by hand took them 3 hours as a group (and the first shift had to do this every morning), which my tool did in 5 seconds with a single button click. They still use it to this day, about a decade later.
This wasn’t something ‘hard:’ I glued a few files together, grouped a list by a filter, sorted the groups by a column, and made a printout which was easy to read and mark on as they went about their day. However, my coworkers didn’t even know this was possible until someone came in with a different skill set, learned what they did (by doing the job well for months) and then made a solution.
You must be careful with doing only ‘hard’ things. It requires other people to identify what is hard! In addition: crackpots do only hard things and believe they find better solutions than what exists so far (without consulting or learning about what has been done). Interesting people learn about things as they are (with the humility of knowing that they are not experts in most things) and tries to improve them using the knowledge they already have.
Don’t waste your time rolling your own crypto when you could do the _actual_ hard thing and identify unaddressed space to make careful and considered improvements.
Re: Never write your own date parsing library
#264Earlier quoted context omitted.
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.)
> "megaseconds" and "gigaseconds" rather than days/years.
More like weeks and decades. Arranging to meet someone in a megasecond is like meeting them on the weekend; a megasecond is ~11.5 Earth days. A kilosecond is short enough to be used for moment–to–moment planning. They’re about a quarter of an hour each so they’re good for scheduling work tasks, scheduling time to meet people for a meal, etc etc.
Gigaseconds are more rarely used, since each one is ~32 Earth years.
Diaspora by Greg Egan has some fun with this too. The main character is a software emulation; called a citizen rather than a flesher. Most emulations live at a subjective rate 800× faster than the flesher normal. The second chapter is three flesher days after the first but 256 megatau, or ~8 years, have passed for the main characters. The fourth chapter is two thirds of a teratau later, over 20k subjective years. For the fleshers of Earth a mere 21 years have passed. The main character has actually forgotten the events of the third chapter; one of his friends brings it up and he has to search his archived memories to figure out what his friend is talking about.
Re: Never write your own date parsing library
#265No 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…
moment.js has been deprecated for, what, close to 5 years now? I wouldn't recommend choosing it over any of the modern alternatives.
Re: Never write your own date parsing library
#266Earlier quoted context omitted.
What do you mean we shouldn't have a first and last name input? explains the naming conventions of every culture on the planet
Which is not relevant unless you are trying to support every culture on the planet. Which most people aren't, and for them it'll be just fine to have first+last name.
You'd be surprised how often two fields mess up names if you live in a place that has any amount of immigration.
Re: Never write your own date parsing library
#267Earlier quoted context omitted.
Your customers will pay more for things that are hard to do. Ask ASML.
> Your customers will pay more for things that are hard to do. Ask ASML. What a silly example. ASML is valuable because it does something no one else does. It's not because it's hard, it's because they have the know-how and infrastructure to do it whereas others don't. Juggling is hard. Do you know any millionaire jugglers?
No one else does it, because it is hard I thought? Hard to get all the steps and processes aligned to produce what they do. It is so hard, that there is no rich guy that wants to throw money in the hat and do it himself.
Re: Never write your own date parsing library
#268Earlier 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.
That trick has been used in movies before that too. "Judgment at Nuremberg" does something similar. A character is speaking German, slow zoom, then a switch to English.
Re: Never write your own date parsing library
#269Earlier quoted context omitted.
Also as an employee, this forces me to job hop to stay relevant.
Unless you happen to live in cultures where that is looked down upon as not able to keep a job.
Meaning you will job hop less, but you still have to weigh the advantage/disadvantage as always.
Re: Never write your own date parsing library
#270When 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,…
I feel obligated to comment on this. Due to my work I rely on web scraped data for cybersecurity incidents. For Amazon Linux, they are disclosed with the fvcked up US datetime format (Pacific Time) and not in ISO8601 formatted strings which could imply Juliet/Local time. In 2007 there was a new law that changed when Pacific Time enters/leaves Daylight Saving Time. Instead of making this fixed by a specific Day of a s…
Reporting of cybersecurity incidents are easily late by a month or more, time zones are well below the rounding error. You will be more accurate to display it as YYYY±6month.