171–180 of 333 posts
Earlier quoted context omitted.
Maybe I’m missing something but then what is 30 days after Christmas? 25389?
25389 mod 365, presumably. The very fancy mainframes probably would pick the appropriate modulus based on whether it was a leap year or not.
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.
Wait so one day over the new year is 2025-01-01 - 2024-12-31 = 20250101 - 20241231 = 8870 i.e. 90 months and 10 days or 7 years 6 months and 10 days How is that the same thing as one day?
2025-02-01 - 2025-01-31 = 20250201 - 20250131 = 70
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,…
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.
In the case of date libraries, I think if I ported the tests from a few well-known libraries to my own, I'd have reasonable confidence in my own. Having said that, I don't think date libraries are hard , I think they're messy . Mostly because humans keep introducing convenience fudges - adding a second here, taking eleven days off there, that kind of thing.
Messy is just a particular kind of tedious which is the most common form of hard.
It's not like typical things that need doing tend to include solving lots of unsolved problems.
IMHO needing to handle multiple, possibly obscure, date formats simultaneously is nearly never a problem in practice.
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.
I like to use the Japanese calendar as an example to scare the juniors away from DIY parsing: https://learn.microsoft.com/en-us/dotnet/api/system.globaliz... https://learn.microsoft.com/en-us/windows/apps/design/global...
Do your users type in such dates? No? Problem solved. The benefit of DIY parsing is to make the problem simple by restricting it to the set of plausible inputs your users will want your code to handle, not to make a highly general library. The right takeaway for juniors is to stop over-complicating things.
This is spot on. So many of the "X is really hard and your intuition is wrong" takes ignore the fact that most people are not building something which needs to be usable in every country, language, and culture on this earth. Yes, human behavior is insanely complex, but for any given application you can probably ignore huge swathes of it.
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…
I think there is missing point in this discussion. Most of the time you build something else. Like if you build a todo app and have to deal with scheduling you don’t spend time making date library because it’s not your goal. But people would do that. Heck most developers instead of starting blog on a blog platform start writing code for their own blogging engine.
Earlier quoted context omitted.
Add phone numbers, email addresses and human names to the list.
What do you mean we shouldn't have a first and last name input? explains the naming conventions of every culture on the planet
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.
I think that advice makes sense in the context of cryptography, where the consequences for getting it wrong can be quite serious indeed. I don't think it holds true for something as unimportant as a date parsing library.