I'm confused. How are you defining "download" and "online" here?

The website suggests that the server holds the files and does the extraction:

Extract and Explore compressed files online [emphasis mine]

which fits with the github claim of:

to view and extract zip files online without downloading them

but the website also states that:

nothing leave your browser

which suggests that the server has nothing to do with it, and you do actually download the zip files first.

What am I missing?

the intent of the code is to get the previous month RELATIVE to the current date.

But that isn't what it does. From the original post:

function getMonthName(monthNumber) {
  const date = new Date();
  date.setMonth(monthNumber - 1);

  return date.toLocaleString([], { month: 'long' });
}

That is a function which is meant to take a number (presumably 1 to 12) and return a localized name for it. This is essentially an array lookup and should return the same output for a given input (and locale) every time it is called. If the intent is to return a value relative to the current date, it is even more wrong, since it should gather the month from the current date, not the function paramenter. This claim of intent, not present in the original post, is an example of you changing your story over time.

Yes, it would help find the problem faster because the first time invalid date is passed in the program will crash.

No, it wouldn't. As I have said before, testing for unexpected return values is just as effective as testing for errors, that is, not very with the function originally presented under sensible assumptions. If the function actually did look like the intent you claim, the tests would be different, necessarily replacing Date for consistent runs, but would be equally likely to catch the problem whether failing on value or error. And if you are eschewing testing and relying on runtime crashes, you have bigger problems.

Given that I have agreed and commiserated, and neither of us can change JavaScript, there is nothing to be gained from pursuing this complaint. In contrast, what I have tried to say, if followed, would give you an approach that leads to more reliable code, even in the face of undesirable APIs.

I had thought that worth pursuing, and had thought you worth investing my considerable time. Alas, I can only lead you to the water...

Yes, and I've said that I agree with that in general. I know that this isn't hypothetical; that's exactly why I keep saying that throwing an error doesn't help you find this bug early at all.

Even the silent weirdness can be caught by the most basic of tests checking output against input, but only if your function works the same way on every invocation.

Whether making a giant fuss (as you'd prefer) or making the best of it (as it actually does), the setMonth method always works the same way. My code always works the same way. The setDate suggestion makes the code always work the same way.

Code that always works the same way is easy to test.

If the day of the month is constant and incompatible with setMonth, whether there's a thrown error or just an unwanted return value, a simple test will reveal that on every test run. If the day of the month is constant and always compatible with setMonth, the test will pass appropriately on every test run.

The bug in the code you originally presented comes from working differently over time. That's why, most days, tests won't identify the problem, even with a fussy, noisy API. Most testing days, the date will just happen to be compatible, and even the fussiest, noisiest API will carry on without any mention of the problem.

The reason the original code works differently over time has nothing to do with the silent, unexpected behaviour of setMonth. It's entirely down to calling Date() without arguments, the entire point of which is to give different values over time. That call effectively introduces state that is not controlled by the function. And not bringing it under control is the real source of the bug.

Yes, absolutely, JavaScript sucks. Make F# the only supported web scripting language! But JavaScript's suckiness is not the cause of this particular bug. JavaScript's suckiness is not the reason this bug is hard to catch. The real problem lies in code that functions differently over time when it should (and could easily) be consistent. That's what actually makes it hard to test.

Plenty of other languages and API design choices still allow code that functions that work differently over time, which is why, as justifiable as the complaints are in general, those factors are irrelevant for this particular bug. Write code that always works the same way and the problem goes away. That's the real core of the issue.

Obviously, that's easier said than done, and it's irritating that neither loud errors nor most testing will help you in this regard, but that's the way it is.

You've replied while I was editing, so see that regarding what I mean by side effects.

As far as throwing an error when you try to create "31st February", this wouldn't actually help much, since the error would still only occur on some days of the year, because your original code doesn't account for the range of outputs from Date() when called without arguments.

To perform correctly, your code needs to normalise the day of the month, or just create the date more explicitly to begin with, but this is a calendrical issue, not a JavaScript one.

If you had a book which had on its Contents page:

Chapter 1 . . . . . . . . . . page 1

and you crossed it out, then wrote:

Chapter 1 . . . . . . . . . . page 1

Chapter 2 . . . . . . . . . . page 50

someone looking for Chapter 1 is still going to find all the text in the right place (as long as it was less than 50 pages).

Changing the partitition table is like changing the Contents page; it doesn't mess with the rest of the data. And if the new table points to the same place it did before, the data can still be found.

That said, if the filesystem still thinks it's 1TB, you may end up with future problems unless you resize it to fit the reduced partition.

I think the assumption is not that adblockers alter the user agent info, but that they also block other resources, so StatCounter won't see those users at all, leading to under-reporting.

Which sampling bias do you think will be ignored by the RETVRN types?

• Worse movies are less likely to survive and be distributed.
• Only 'classics' will overcome a preference for watching newer movies.

"Instance" seems too jargon-y to me as well, and "proxy" is even worse. "Server" and "host" are probably a little more familiar, but are still technical language.

Confusion doesn't stem from individual words; people need explanations and examples, but, as an alternative to "instance", if you want to extend the "communities" metaphor, then "society" as a cluster of communities is a natural option, particularly since it relates to the widely understood concept of social media. Since most people using the Internet also know what a web "site" is, you could use the sibilant linguistic association to help cement the notion:—

Each society has its own web site, such as:

• aussie.zone, where the communities relate to Australia;
• programming.dev, where the communities discuss software development;
• and lemmy.film, where the communites are about movies.

You can choose which society you want to join, although some will ask you to fill out an application. Most societies have connections to others, meaning that you can discuss things with people who are part of different societies. Often, you'll recognise them by their username saying that they're at (@) another site. Not all societies get along with one another, so which one you join will also affect who you can talk with.

Each society has its own rules it expects you to follow, whether you are a member of that society or just visiting.

This kind of language seems more intuitive to me anyway, although when I've tried describing instances and federation before now, I've likened instances to countries:—

You choose somewhere to live (and you can move later if you want). If there's a cross-border agreement, then you can send messages back and forth between people in each place.

but this has also meant stressing that your instance "country" doesn't have to match where you physically live, so a more general term probably would have been more useful.

For someone seemingly so eager to try out new distros, I'm surprised you haven't mentioned virtual machines. If the vibes are off, it's a whole lot less disruptive to find out that way.

Your experience with drivers won't be quite the same as a bare-metal installation, but checking out software shouldn't be a problem.

The end of "Cogenitor", where Archer blames Trip for the death of Charles.

I don't see them in the app, so not yet, I guess.

Uh, the XiBucks, obviously.

Look, I get it. Hexbear is a demanding place to be. It expects you to not be a complete asshole almost all the time. You're regularly tested on knowledge of an emoji system so complex, it's been known to make London cab drivers cry. If you unthinkingly parrot talking points, you'll be pounced on with annoying facts and aggressive reasonable concern for the value of other people. And if you emit the slightest Hitler particle, you'll be outright banned. How authoritarian! Honesty, sometimes I wonder why I signed up, never mind stay around.

But then I remember that the folks there are a deeply caring lot, who see the problems in the world and actually want to do something about it—even though the goal often seems barely possible—and, in spite of everything, retain a sense of humour and try to make improvements for each other, even if, for now at least, it can only be a :meow-hug:.

Oh, and the XiBucks, of course. Some of us even get roubles, too!