History of Zero-Based Months? • Hacker News Board

Re: History of Zero-Based Months?

#11

Post by stickfigure » Sat, Aug 27, 2022, 2:58 PM UTC

sexy_panda wrote: post #5

schot wrote: post #4

"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?

We enumerate milliseconds since 1 Jan 1970 12am UTC instead. You can convert to all the other formats.

Re: History of Zero-Based Months?

#12

Post by mort96 » Sat, Aug 27, 2022, 3:09 PM UTC

stickfigure wrote: post #11

sexy_panda wrote: post #5

Earlier quoted context omitted.

Why don't we enumerate days throughout the year?

We enumerate milliseconds since 1 Jan 1970 12am UTC instead. You can convert to all the other formats.

Well, given a database of leap seconds you can. And you can't convent times in the future between unix time and calendar time.

Re: History of Zero-Based Months?

#13

Post by lofatdairy » Sat, Aug 27, 2022, 3:10 PM UTC

The 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

Re: History of Zero-Based Months?

#14

Post by zamadatix » Sat, Aug 27, 2022, 3:52 PM UTC

mort96 wrote: post #12

stickfigure wrote: post #11

Earlier quoted context omitted.

We enumerate milliseconds since 1 Jan 1970 12am UTC instead. You can convert to all the other formats.

Well, given a database of leap seconds you can. And you can't convent times in the future between unix time and calendar time.

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.

Re: History of Zero-Based Months?

#15

Post by nayuki » Sat, Aug 27, 2022, 3:55 PM UTC

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()]);

Re: History of Zero-Based Months?

#16

Post by photochemsyn » Sat, Aug 27, 2022, 4:40 PM UTC

I 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.

Re: History of Zero-Based Months?

#17

Post by stingraycharles » Sat, Aug 27, 2022, 4:59 PM UTC

nayuki wrote: post #15

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()]);

Is subtracting 1 really that much an inconvenience, given how awkward they are?

Re: History of Zero-Based Months?

#18

Post by _kst_ » Sat, Aug 27, 2022, 6:34 PM UTC

DonaldFisk wrote: post #3

gerikson wrote: post #2

At 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.

How 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.

About as difficult as it is to add 1 before printing the month as a number.

Re: History of Zero-Based Months?

#19

Post by pvorb » Sat, Aug 27, 2022, 6:44 PM UTC

nayuki wrote: post #15

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()]);

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.

Re: History of Zero-Based Months?

#20

Post by mort96 » Sat, Aug 27, 2022, 7:03 PM UTC

zamadatix wrote: post #14

mort96 wrote: post #12

Earlier quoted context omitted.

Well, given a database of leap seconds you can. And you can't convent times in the future between unix time and calendar time.

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.