Zero-based months is awkward when printing as a number, but convenient when indexing an array: const MONTHS = ["Jan", "Feb", "Mar", ..., "Dec"]; console.log(MONTHS[d.getMonth()]);
[deleted]
History of Zero-Based Months?
21–30 of 30 posts
Re: History of Zero-Based Months?
#22> One-based indexing for the year and day,
Year is 0 based too
Re: History of Zero-Based Months?
#23"Why is day of the month 1-indexed but the month is 0-indexed in C?" This Twitter thread from November 2020[1] and its HackerNews discussion[2] seem relevant. 1: https://twitter.com/hillelogram/status/1329228419628998665 2: https://news.ycombinator.com/item?id=25195287
Why don't we enumerate days throughout the year?
you can if you want: new Date(2022, 0, 236) is the same as new Date(2022, 7, 24)
Re: History of Zero-Based Months?
#24> One-based indexing for the year and day, Year is 0 based too
Year 0 doesn’t exist [1], and I wouldn’t regard years as being indexed. How would you represent 1 BC, with a negative index?
Re: History of Zero-Based Months?
#25Earlier quoted context omitted.
Why don't we enumerate days throughout the year?
Probably because most calendars started as lunar or lunar-based. There is also the case that separating the year by month could be beneficial for farmers back in the day to plan different activities throughout the year. I've always like the names of the months in the French Republican Calendar[1] because of that. [1]: https://en.wikipedia.org/wiki/French_Republican_calendar#Mon...
Excellent historical exploration of the topic => https://youtu.be/iBRCL090PxA
Re: History of Zero-Based Months?
#26Zero-based months is awkward when printing as a number, but convenient when indexing an array: const MONTHS = ["Jan", "Feb", "Mar", ..., "Dec"]; console.log(MONTHS[d.getMonth()]);
Yes, that was always my theory for why months are 0-based. Back in the days of early Unix, this might have had a tiny performance benefit that was enough for them to choose that implementation.
I think that it should be unnecessary. The address of the array could be adjusted at compile-time so that one-based index numbers will be possible.
Re: History of Zero-Based Months?
#27> One-based indexing for the year and day, Year is 0 based too
Year 0 doesn’t exist [1], and I wouldn’t regard years as being indexed. How would you represent 1 BC, with a negative index? [1] https://en.m.wikipedia.org/wiki/Year_zero
Year zero will be possible with astronomical year numbering. In this case, 1 AD will be +1, and 1 BC will be 0, and 2 BC will be -1.
Re: History of Zero-Based Months?
#28I think it's important to be able to work with mod(%) 12 for some operations on year month relationship. All years have 12 months. For day of the month you need additional logic to handle diferent lengths... and other issues.
This reason makes sense. Note that different uses will have different useful conventions, and converting between them may be necessary. (Although this is true of more than only month numbering.)
Re: History of Zero-Based Months?
#29Earlier quoted context omitted.
Times in the future are always unreliable, even using the "normal" system there aren't any guarantees that specific time will even exist or if it does you still need to think about "is it an absolute event or a relative event and does it need to have the time updated as a result" just the other way around.
Sure. But the important difference is: I can express the time "2nd of March 2056, 15:00 UTC", we can talk about that future time, and we can tell whether we're before or after that time. But I can't express the same time in unix time, because I don't know how many leap seconds will be between now and March 2056.
Sure you can, just allow for sticking the things you want to track against at the end like you did after saying "2nd of March 2056, 15:00". If that's leap seconds then there is no reason you can't say " with leap second changes" just the same as you did there with a datetime. What you can do with a timestamp is a superset of what you can do with a datetime since you start with fewer limitations but lose none of the ability to apply or mark needed transformations to that base:
Guarantees about UTC:
- Can calculate duration from past to : No (need future leap second table)
- Can calculate duration from now to : No (need future leap second table)
- Can calculate duration from future to : No (need future leap second table)
- Can compare to : No (UTC is not monotonic)
- Can know if is unique: No (UTC is not monotonic)
- Can determine has passed: After passing
- Can determine will occur: After passing (time skip adjustments and whole date skips allowed in calendar)
Guarantees about timestamp:
- Can calculate duration from past to : Yes
- Can calculate duration from now to : Yes
- Can calculate duration from future to : Yes
- Can compare to : Yes
- Can know if is unique: Yes
- Can determine has passed: Yes
- Can determine will occur: Yes
Once you add "accounting for leap seconds" to the timestamp all but "Can determine will occur" will match up. UTC didn't gain anything over timestamps in that case the difference between the two just shrunk.
While you may be able to say "I know what the UTC encoding will look like ahead of time if I specify it in UTC encoding" that doesn't actually give you any more information about the time as you can't do anything functional with that knowledge until the time passes at which point, provided the same info you had to accurately track the UTC time, you have enough information to do the same with a timestamp.
Re: History of Zero-Based Months?
#30Earlier quoted context omitted.
Yes, that was always my theory for why months are 0-based. Back in the days of early Unix, this might have had a tiny performance benefit that was enough for them to choose that implementation.
I think that it should be unnecessary. The address of the array could be adjusted at compile-time so that one-based index numbers will be possible.
I think people are overestimating the features of compilers. Today's compilers might struggle with that. 70's compilers even more.