- https://infiniteundo.com/post/25326999628/falsehoods-program...
- https://infiniteundo.com/post/25509354022/more-falsehoods-pr...
In my experience engineers will often brush these sorts of things off as “edge cases”, but really all of these complexities are just how dates and time work in the real life (I’d argue that they’re just “normal cases” to test for)… So any anomaly in software will cause real problems of varying importance for users.
I'm not interested in long theoretical articles. But I would look at 3 lines of code.
I'd agree that it feels like that quiet often as a web developer, but that's only because most of our APIs are actually quiet easy to use.
The illusion usually falls away if you look at the code of that API, however.
Those articles are more empirical in nature than theoretical.
> This logs that an image with a given id was updated
As a thought exercise, imagine that your log trail needed to be created in a distributed system, spanning multiple machine time zones, or that you needed to build a report that is read from browsers in multiple time zones that differ from multiple differing written time zones, and you need to account for human readable things like knowing what day of the week it is and what some given locale calls that day.
If you are doing the equivalent of printf debugging with your times, maybe you likely don’t need a time library.
If you are using time as a central part of a distributed algorithm, web content, or a business workflow, then you may likely need a time library.
I heard it very often. I don't buy it. Any system, no matter how complex, can be composed of small, simple systems.
I never ran against a "complexity wall" when writing software in a lean way and suddenly thought "Damn, those tens of thousands of lines of library code now would be the better approach".
Sound software construction techniques are one thing, but convincing someone to pay you to reinvent the wheel is another.
Especially when you consider that budgets for new, bespoke brand websites can start as low as about a couple of days pay for a senior developer.
Libraries come in handy when doing things that aren’t one liners.
A colleague thought it was super easy to change that exact ISO string to use the local timezone instead of UTC, against my advice. Guess what. The minus sign broke it and he would have never known because most customers are in the US, then they travel to Singapore and your product is worthless. By the time you hear about it, you lost the customer’s money and time therefore you lost the customer.
Moment and Luxon are too heavy, I agree, but date-fns isn’t.
User: set an alarm in eight hours.
User: remind me to brush my teeth on November 21st at 8AM.
User: please note my doctor's appointment next week at 10AM.
---
tl;dr It's not just an issue of storage.
I mean, there is no way to write code to “handle” this that isn’t just guessing on the part of the programmer. The correct thing to do is to prompt the user for verification or further information.
> There are requirements that we, as humans, will intuitively find the right interpretation for…
Interpretation is subject to error. (Yes humans have immensely more context to work with than computer programs, but just because we we’re better guessers doesn’t mean we’re not still guessing.)
You could make an argument that there are more important things to fix, but then you’d be deciding consciously that it was okay to ship software known to be incorrect.
The js date is a bit primitive and moment looks easier but in practice it's actually a convoluted clunky type system that hides important nuance behind impressively bad defaults
I used to get immediate hostility and belittling insults when I stated this about 10 years ago. I think people have finally come around. Let's see how the replies go
It's been like this for decades. Emotional salience sells software better than hard practicality to just about everyone. Then people rationalize their irrational choices then the timeline slips and the product sucks.
You can just sit and watch it play out like someone studying monkeys. It's remarkably predicable.
This wasn't anything about the posted software. It was a reply to a comment.
Formal peer-review does trump download count, nonetheless.
And I’m all for professional licensure, continuing education programs, and formal, public reviews of the software engineering behind the open source libraries that comprise global infrastructure.
Your main point wasn’t missed.
Tell me if you've ever had this experience.
You see something that looks like it's pretty popular. You try it. You find it has nothing but problems. After much research you then find out that other people don't have the level of sophisticated asks for the product and they are doing less complicated and less critical things.
It's the disconnect between the hype and the reality that really rubs me the wrong way. I've personally lost so much time on inappropriate tools.
Again I'm not here to insult anybody specifically or to speak poorly upon any specific product. I know how many people read these comments and I don't want to cast shade on anybody's hard work. I just wish there was more authenticity to the fit and purpose of things.
I know a lot of this depends on the users. I speak as somebody who has very popular projects and very not so popular projects. The popular ones are hyped (but sarcastically) and the ones that I worked very hard on to be extremely technical about do quite poorly.
To make things super current I haven't working for about a month on an article and I have been making sure it is extremely accurate and I know that that will probably hurt me because the liberties which inherently contain inaccuracy are simply more entertaining
This is a shared experience except for a select few. This carries is over to other things. Inaccurate pop science is read much more widely then the direct research material. There's something more emotionally approachable through this tactic. It just hurts productivity and it's a shame
Quoting your writing that is probably rubbing others the wrong way, as it certainly reads easily as being specific to “these” solutions, as you put it.
You might avoid triggering people’s negative emotions by sticking to your main point and avoiding the marginalizing.
This is so vague. Can you say how you're relating this to dayjs? How is its purpose inauthentic?
Thanks for being an unproductive asshole
Better luck in the 2030s I guess
You described your comment being an attack on modern development culture, as your use of euphemism, you chose the insultingly denotative word “kid” to attack the project.
Cool attitude, too?
You're being sloppy imprecise and presumptive once again. I'm noticing a pattern here. Let's see if it comes in threes.
And in case you're wondering, you're the one who set the rules of this engagement, I'm only playing by them.
We can be adults any time you want.
Nothing about that comment was belittling or hostile. It was a bit snarky, but with very good reason, and did not name its target.
What is one month ago when you are March, 31st?
We have to deal with monthly subscriptions and it's not fun.
No library can help you with that. You have to define what you actually want to calculate.
Time libraries can help you with that.
This discussion reminds me of this bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1715455
"one month ago" is between "a few weeks ago" and "a few months ago".
>We have to deal with monthly subscriptions and it's not fun.
it is a lot less unfun if you define a month as N calendar days in your terms of service, like virtually everyone does
This is why we don’t let engineers write contracts. Many seem to think that law is a programming language in which they can redefine reality. It ain’t.
And... it's a multi tenant system, where some organizations use Sunday as the start of a week, and some use Monday. And they all want to be able to switch.
In addition, should the legal authority in timezone B change their DST rules in the meantime, the local time of the event as observed in timezone B should still be what the user initially selected, which is not the same in UTC as it was at creation time
I just use what the native Date() object offers.
Other devs always say "Just wait, one day it will fall on your feet".
But this has been going on for many years, in which my software has served millions of users and nothing ever fell on my feet. I think the complexity of a library like this (423 files, 1433 commits, 53004 lines of code) would have created more problems during this time. So not using one is a net positive.
Any minimal code example of what is prone to break without a date library and how this date library is supposed to prevent it?