Hacker News Reader

Comment by mikeocool | Hacker News Reader

Wahoo, it doesn't use 0-indexed months! Probably the biggest cause of bugs with js Date objects.

That does remind me: why that even is a thing? Ordering days of a week from zero can make sense since there is Monday/Sunday as a week start divide, and this can be seen as a bypass (0/7 as Sunday and 1 as a Monday), but with months?

Zero indexing for arrays/collections generally makes sense. If you had the months in a normal array they would obviously be zero-indexed (unless you deliberately put a placeholder value in the first position in the array, which would be pretty weird since all the normal ways of getting the first thing in the array would break).

The reason it apparently feels weird to many people to have months be zero indexed is that months are often referred to by their ordinal number, and ordinal numbers obviously start at 1.

> months are often referred to by their ordinal number

What do you mean by “often”? Humans always use ordinal numbers for counting things like months, days, weeks, etc. There is no concept of 0 to be applied here, except for programming array indexing purposes.

Lay people indicate the month with an ordinal all the time since it's how dates are standardized (12/30/2021). People don't often indicate the day of the week with a number, they use "Monday" or "Tuesday". So there's no strongly held convention in people's minds about how to number days like there is for months.

It is lifted from C's struct tm. If you're maintaining tables of month names you're going to 0-index them so tm_mon is 0-based to facilitate that.

What I mean is that people use the ordinal number as the name of the month (as well as the day of the month). If you ask someone their birthday they’ll often say something like “five twenty, nineteen eighty-four.”

This is a potential cause for confusion when writing computer code, because it’s very common for code to refer to items in a collection starting at zero.

Side note regarding humans: I was in a hotel in France that referred to the ground floor as "floor zero" in their elevator. The only time I've ever seen zero used to count something IRL.

This is actually a decent way to demonstrate why zero-indexing for arrays makes sense. If your friend gives you instructions to their apartment “go to the elevator in the lobby and go up 3 floors,” which button do you press in the elevator?

I don’t follow? Even in your specific example, it would be +3 to whatever floor the elevator says you’re currently on. Though, usually people refer to the exact floor number per the elevator signs.

Even if this is true, days in JS still start at 1. It is inconsistent.

Zero indexing of arrays only makes sense in C because array variable is a pointer to first element of the array. In all languages that have actual array type with length and bounds checking, 1 would be a better way to index arrays most of the time and having specified valid range would be the best way.

The week starts on Monday in most of the world.

Date & time APIs must match local reality.

When reality differs by locales, at least one "local reality" won't match the API.

https://stackoverflow.com/a/41992352

> it was copied from Java's JDK1.0 (1995) java.util.Date, which also had this quirk

No. It’s definitely older than that.

https://mobile.twitter.com/hillelogram/status/13292284196289...

Just because the issue predated Java doesn’t preclude the fact that the initial JavaScript Date implementation was lifted from java.util.Date. Brandon Eich has explicitly stated it was so.

https://maggiepint.com/2017/04/09/fixing-javascript-date-get...

https://twitter.com/bahstgwamt/status/867609109276872704?s=2...

Twitter is such a bad platform for this. Code in images means it's completely inaccessible to the blind and very inaccessible to people with poor vision, and you can't copy and paste it into an editor for syntax highlighting or better examination.

Another one is JS parsing numbers with leading zeroes as octal (unless specifying base, which is why linters are so strict on it). Often surfaces when parsing date strings.

That hasn't been the case in JS for almost a decade.

parseInt('0700') returns 700. But parseInt('0x700') will be parsed as octal, so now it's just a more subtle gotcha.

Loose parsers (such as parseInt(), and Date.parse() in JS) are one of the worst ideas ever. Nothing like tracing a bug, and finding that a junior dev is trying to parse DD/MM/YYYY strings using Date.parse(), except that instead of throwing on trying to parse an incorrect [non-RFC] format, the parser makes a best-guess and propagates an incorrect date because it was parsed as MM/DD/YYYY.

Not sure why any api ever had functions like float.parse(s) or date.parse(s). Even more modern ones like .NET (circa 2000) had it. And it's literally never a good idea. Not even for a one off script is it convenient or ergonomic to omit the information about what format you expect (or try to suck it out of thin air such as a static locale on the thread). It's just a bad.idea. If it does accept date parse(s) it has to be with a fixed format (e.g. iso) unless specified. Not "system local format" or something. The same applies to number formatting. I haven't met one single person who prefers automatic string formatting to switch decimal point and decimal comma due to the system language.

I wonder how much of that has to do with the fact that ISO8601 was relatively newer back then (published 1988), and date formats were much less standardised 20+ years ago.

For instance, RFC 1945 (HTTP 1.0) specifies three acceptable date formats. Add ISO dates, and now you're writing software that needs to handle 4 different formats. Easier to just use a heuristic parser that's capable of accepting HTTP, email, Usenet, and ISO timestamps.

Fortunately, these days it's generally considered a bad idea to use anything but ISO timestamps, with the exception of a former colleague who tried arguing that DD/MM/YYYY was an acceptable format to be transmitting and storing dates in.

Why would you not have a parseFloat/float.parse/whatever?

Parsing floating point values correctly is not a trivial amount of work - to the extent that there have any been security vulnerabilities in implementations.

Of course it should be a api but it should be either explicitly requiring a format OR (more likely) default to an invariant format.

That is, if I do this

    float f = 123.456;
    Console.WriteLine(“value is “+f);

The output shouldn’t vary depending on whether it’s run in France or the US (which it does by default).

For parsing, the argument should even be explicitly required I think. So

    float f = Float.Parse(“1,23”,  frenchLocale);

So that it’s not ever forgotten or the reader has to wonder if the author forgot it.

JavaScript’s numeric parsing is locale independent. People write too much code blindly to make any kind of locale inference anywhere.

Otherwise I agree with you whole heartedly - I have been stung by absurd locale dependent behaviour in the past (windows’ font loading APIs inexplicably translate the font variant in the programmatic api)

They are not arguing about the stdlib including them, but the api they choose. Instead of parseFloat(str) that tries with a system dependant comma or period, have the decimal type be a parameter or have two explicitly named functions.

Same with dates. Don't try lots of formats on an arbitrary string, force the user to specify the expected format somehow.

Years aren't 0-indexed either. Nobody has a problem with that.

How do you know they aren't? What happened in 1 CE? What happened in 1 BCE? What happened during the year in between?

There isn't a year between them.

In most calendar systems there is. Perhaps there isn't in your favorite calendar, or perhaps you just don't know about it. For instance, the subject of TFA is based on the "Proleptic Gregorian", which does have a year zero.

Reply on news.ycombinator.com