Hacker News Reader

Comment by CA0DA | Hacker News Reader

"January is month 1"

This is what we were all waiting for.

What is Monday and Sunday?

edit: The dayOfWeek read-only property gives the weekday number that the date falls on. For the ISO 8601 calendar, the weekday number is defined as in the ISO 8601 standard: a value between 1 and 7, inclusive, with Monday being 1, and Sunday 7. For an overview, see ISO 8601 on Wikipedia.

They had me at “all objects are immutable.”

They lost me at “ date time values without time zones.”

I’m mostly kidding with the second line. Working with third-party React calendar components requires doing some moment.js math and then hacking off the last few characters of the .toISOString() to make the calendar happy. So I can see how it’s a very practical addition. Please don’t misuse it.

They lost me at “ date time values without time zones.”

This is rather useful for date of birth, which shouldn't be set to a time zone in most use cases (it can get rather confusing if you do).

Every DOB field I’ve seen is just a date, with no timestamp at all.

There’s a footgun when you convert DOBs to Date objects. This can return different dates depending on the local timezone:

``` new Date("1/1/2021").toLocaleDateString() ```

If you want it to return the same DOB regardless of local timezone, you have to pass a timezone to the Date constructor, which is not super obvious. This kind of bug is also unlikely to get caught by unit tests unless you’re testing date formatting for different timezones, which you probably wouldn’t do if you’re not aware of the footgun to begin with.

Were we? Would have made more sense to change the day-of-month to be zero based too IMO. Or explicitly have both: `monthOne` and `monthZero`.

Why would you want that? It is super confusing since 1~first as well as every real life date representation I know has 1=January

Because it only needs to be "1" when you format it for human consumption. 0-based is much easier to work with internally.

> 0-based is much easier to work with internally.

Why's that?

Even if it was I'd still want days and months to start at one and, you know, match everything else in existence that represents them.

Mainly because you can use normal modulo arithmetic and use them as array indices.

But as I mentioned in another comment, really you should be touching the internals of the datetime object at all. It's a mistake to do something like `myDatetime.day += 1`. You should instead do `myDatetime + timeDelta(days=1)` or something.

So it shouldn't matter whether it's 0-based or 1-based at all. But since it apparently does (I don't know why), then it might as well by 0-based like everything else.

No it doesn’t. Dates aren’t meant to be worked with as raw numbers, so the utility of 0-based numbers is gone and now you only have February ending on day number 27

If people don't work with them as numbers then the argument is completely moot. All you need is timestamps, deltas and formatting functions.

How many days is in the delta 1 hour? 1? or 0?

The whole reason months start at zero is because somebody wanted to work with them as raw numbers.

Yes and they were wrong. There’s a whole “misconceptions programmers have about dates” you might want to read. The only number for dates is the Unix timestamp.

So if I want to have a style per month or something in my program, I'm wrong? If I want to select the next month's style I have to do something awkward like `(current mod 12) + 1` instead of the more natural `(current + 1) mod 12`?

Then why do days not start from 0. If that argument is value it should be applied consistently so 2000-01-01 is day=0, month=0.

Probably because the ancients didn't have a strong grasp on the number 0.

Midnight is zero. What's confusing about the number of days starting from 0 too?

Why do we use months? No sane internal representation stores the number of months. They are completely and utterly useless and exist only in printed representations of dates.

Props to the Mayans, whose dates are (almost) a base-20 number counting from the Mayan date of creation. It's not fully base 20, because the 2nd digit only counts to 18 because 360 is close enough to a year. So 13.0.5.17.19 is followed by 13.0.6.0.0 instead of 13.0.5.18.0. Bonus points: no leap years to worry about!

The downside is that their full calendar is somewhat more complicated, so they would say that today is (checks) 13.0.8.11.11 8 Chuwin 9 Sek, and tomorrow is 13.0.8.11.12 9 Eb' 10 Sek (that Tzolkin calendar component doesn't work like our months do!).

I was meaning in the context of JavaScript, where the first day is 1 and the first month is 0.

A case can be made for either 0 (for consistency with time representation) or 1 (to go with the defacto standard of how most if us bipedal meatsacks process dates) but there must have been alcohol or something stronger involved when the current date object came into being.

Erm... nobody was arguing for it being the current way. That's retarded. This whole thread is about making them both 0-based rather than both 1-based.

0-based months were meant to assist with lookups in 0-based arrays.

ISO 8601 says January is 1. We have a standard.

ISO 8601 is a serialisation format. What's your point?

What is "January" -> "1" if not serialization?

Point is: there is a standard. Use it.

Are you suggesting JS printed "ISO 8601" strings with 0-based months before now?

Do people really not know the difference between internal representation and serialisation? Are we even speaking the same language? Truly baffled by this.

Reply on news.ycombinator.com