5 ms·
History of Zero-Based Months?
- gerikson 4y agoAt least in Perl, the rationale for this (apart from copying C) is that it's very easy to reference a list (array) of month names if the month indices are zero-based.
- DonaldFisk 4y agoHow difficult is it to either subtract 1 before indexing your array, or have a 13 element array with a dummy value in element 0? Deprecate time.h and adopt ISO 8601 already.
- schot 4y ago"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 https://twitter.com/hillelogram/status/1329228419628998665 2: https://news.ycombinator.com/item?id=25195287 https://news.ycombinator.com/item?id=25195287
- sexy_panda 4y agoWhy don't we enumerate days throughout the year?
- masklinn 4y agoBecause we don't. Which is probably because it's too fine a granularity, especially historically: even an ordinal month-day had limited use to preindustrial contexts were time-boundaries were necessary quite fuzzy owing to the vagaries of communications or transport. Technically you don't need years either, but chunky boundaries are useful as both reference points and communication shortcuts.
- ainar-g 4y agoProbably 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#Months https://en.wikipedia.org/wiki/French_Republican_calendar#Mon...
- smitty1e 4y agoExcellent historical exploration of the topic => https://youtu.be/iBRCL090PxA https://youtu.be/iBRCL090PxA
- stickfigure 4y agoWe enumerate milliseconds since 1 Jan 1970 12am UTC instead. You can convert to all the other formats.
- mort96 4y agoWell, given a database of leap seconds you can. And you can't convent times in the future between unix time and calendar time.
- zamadatix 4y agoTimes 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.
- _OOps_ 4y agoI 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.
- jefftk 4y agoThis could still work: https://news.ycombinator.com/item?id=32618016 https://news.ycombinator.com/item?id=32618016
- zzo38computer 4y agoThis 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.)
- lofatdairy 4y agoThe same justification exists in JS (where it's copied from Java which copies it from C). However, interestingly checking the FORTRAN IV specification documents for the PDP-10, it's not implemented as a 3 letter ASCII abbreviation. That document dates to 1975, I don't know if I can find if the date exists in the first version of the document, which should date to 1967. I was unable to find a reference to a builtin in the base FORTRAN II, which only provides 20 builtin functions, date not making the list. I think newer versions of FORTRAN77 has idate which is 1-indexed but I couldn't find it in the older standard listed on wg5's specification documents. [^1]: https://github.com/PDP-10/f40/tree/master/doc https://github.com/PDP-10/f40/tree/master/doc
- nayuki 4y agoZero-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()]);
- pvorb 4y agoYes, 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.
- zzo38computer 4y agoI 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.
- pvorb 4y agoI think people are overestimating the features of compilers. Today's compilers might struggle with that. 70's compilers even more.
- stingraycharles 4y agoIs subtracting 1 really that much an inconvenience, given how awkward they are?
- deleted 4y ago[deleted]
- photochemsyn 4y agoI think it all comes down to whether you're counting elements as the primary goal. However, months are poorly defined relative to something like an astronomical year or a standard day, so they're more like objects. That is to say, adding different months doesn't give you the same number of days as a result. Hence, dealing with months is perhaps a bit more like indexing variable-sized objects, and for that purpose traditionally, the array-of-pointers approach uses zero-based pointer arithmetic, which is what the designers might have been thinking. Really however, the months should probably be treated more like structs, with the number of days in that month being a data member. This would allow sanity checks, i.e. entering Feb 30 should raise an error, but not May 30.
- 11235813213455 4y ago> One-based indexing for the year and day, Year is 0 based too
- bouke 4y agoYear 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 https://en.m.wikipedia.org/wiki/Year_zero
- zzo38computer 4y agoYear 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.