Why is day of the month 1-indexed but the month is 0-indexed in C? | Hacker News Reader

Why is day of the month 1-indexed but the month is 0-indexed in C?

twitter.com

78 pointsazhenley37 comments

Summary:

For historical reasons.

When displaying the day of the month, we wanted to print "1" so we stored that.

For months, we wanted to print a 3 letter abbreviation, so we had a string ("JanFebMar...") and we stored an index-0 value to start at the first entry of the months string.

So the day of the month is just a number but the month is index, I guess.

Thank you for the summary. These twitter threads are difficult to read, especially on mobile.

Days are natural numbers.

Months are a string array.

It seems intuitive to me. If you looked at a calendar and typed the data, that’s what you’d end up with.

Month is not always string array, for example in ISO: 2020-11-23.

And days can be string as well: "1st November".

It was a string array first. ISO came long after the Gregorian calendar. And the months came from the Julian calendar.

If we go all the way back, one could say it was a mixed array of string and integer. September (7), October (8), November (9), and December (10) are linguistically ordinal names... but they’re all off by two since the deprecation of the Roman calendar.

Since Julius and Augustus.

(written 4 Freezy 229)

It was a list of names long before it was considered "a string array".

Actually the Romans counted their months beginning with March:

March (1) April (2) May (3) ... July (5) (named after Julius Caesar) August (6) (named after Augustus) September (7) ... etc.

The reason being in the ancient world all serious activity begins in the spring, especially war campaigns which were to be under the aegis of the god Mars, from which the name of the month.

Note that when we have a leap year we add the extra day to the end of the Roman year, that is at the end of February which is the last month of the year.

More precisely, we duplicate the sixth of the calends of March. This is why in French the leap year is called 'bisextile'.

This is the correct answer.

Months often need to be translated to a name.

A day of month is not translated to a name.

I’d argue that the day of month is overwhelmingly described with a name corresponding to its 1-index.

So there's that too then. :)

Well, if everything were based on how it appears in a calender, you'd think that Americans would start their friggin dates with the month, too ;)

In German I'd say that both two number dates (lit. "schedule a meeting for the ninth eighth") as well as month names (lit. "my birthday is on the eighteenth May") is common, so we might be more accustomed to thinking of months as numbers. If Roman emperors would've done a better job, we all would.

I think Windows does months as 1-indexed, but then makes a mess of days of the week.

> you'd think that Americans would start their friggin dates with the month, too

We... do? America writes dates such as March 14th 2020 as 3/14/20. ISO 8601 is of course superior but I like the month-first approach, because "the 14th day of" doesn't tell you anything until you know "March", it seems more natural.

Sorting becomes so much easier though wenn its yyyy-mm-dd

Too early today for me to write posts ;)

"Year" first would be more the point where it gets confusing, as when you really start reading the details from a calendar, the year would be first, too. (When you're actually talking, of course, the year is rarely mentioned.)

I'm just saying that going from how you say something in your native language to internal data representation is quite error-prone.

I actually find the European custom more logical.

If we are having a casual conversation and I’m referring to a previous event that happened on the 14th, you can assume from context that I mean the 14th of the current or previous month (eg the 14th of November as of the writing of this comment). If it isn’t the current month (+-1 based on context), I can instead specify that I meant the 14th of September and you will understand that I mean the 14th of September this current year (again +-1 by context). If I meant the 14th of September, 1987, I will say the whole date. But since most date-based conversations have an implied context, being able to simply truncate dates for brevity is useful.

ISO 8601 is big-endian, European style is little-endian, and US-style is just kind of pointless.

> ISO 8601 is big-endian, European style is little-endian, and US-style is just kind of pointless.

US-style is middle-endian.

Lots of News websites give month and day, but no year.

"March" doesn't tell you anything until you know 2020. It seems like you need the entire date before you know anything at all, so I don't think this argument holds. I think it's arbitrary like most natural language. There is no logic, it's just like that because people do it that way.

Not true, if I say "my birthday is in March" you know something about every year. If I say "my birthday is the 14th" you know... nothing useful.

It is of course arbitrary, like anything in natural language; if I thought it were a matter of logic, I would have said something other than "feels more natural"!

I name-checked ISO 8601 for a reason; that's how I write my dates now, and as a developer, if you store dates as anything other than a Unix timestamp or ISO 8601, I judge you for it ;)

but you'll notice it puts the month before the day...

That's true for anniversaries. Some things happens every month too. "I get paid on the 29th". "The bill is due on the 1st".

ISO-8601 does indeed put the month before the day, but it puts the year before the month too. The problem people have with the American format is that it's mixed. Y-m-d makes a lot of sense, but d-m-Y kind of does too. m/d/Y is just weird and it's literally the only country in the world to do it.

"March 14th 2020" is perfectly fine both when spoken and written. It's not easy to sort lexicographic by programs, but that's not the most important aspect.

The problem is that the existence of both MM/DD/YY and DD/MM/YY makes dates less than the 13th of the month ambiguous. People do seem to get hung up on not going from smallest to largest unit (or the other way around), but the ambiguity is the real problem in my opinion. And of course it becomes a tribal thing, "the other guys are wrong about their format, we should keep ours and drop theirs". The best thing would be to just drop MM/DD/YY and DD/MM/YY in favor of _any_ format that is universally understood as unambiguous.

I learnt this the hard way the other day that this is the case with Postgres too. Its very jarring in my opinion that we have to write date(1, 0, 2020) to mean 1st Jan - the date and year are fine but we suddenly need to minus one in the middle

One has to wonder how many gigajoules have been saved on Earth because of that one optimization. There are a lot of date columns out there.

Is make_date not available in your installation?

https://www.postgresql.org/docs/9.5/functions-datetime.html#...

It's not just in C, by the way. It's the same in the Java Date class [0]

[0] https://docs.oracle.com/javase/7/docs/api/java/util/Date.htm...

which inherited it from C.

Which is one of the worst designed APIs in Java:

https://stackoverflow.com/a/1969651/130659

The answer is right there in the text from K&R. `tm_mday` is day of the month, `tm_mon` is months since January. There's nothing else to it really. The first month of the year is not "1", it's January. In any case, this is all about how we display dates and it's all rather silly and it's best not to think about it too much.

An unrolled version of thread, I find it easier to read this way:

https://threadreaderapp.com/thread/1329228419628998665.html

I'm planning on writing this up into a full blogpost, so people won't have to deal with the terrible Twitter UI. I just like Twitter because it's a fun writing constraint ¯\_(ツ)_/¯

It’s be funny if this went back further to some pre Unix telco system, my hunch was some date conversion optimization.

Doesn't predate Unix according to him

> I stopped at Unix 5, from 1974. It didn't even have a <time.h> file! In its <ctime.c> file, it stores the date as an array of integer values. The `tm` struct only starts appearing in Unix 7.

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

Although the source for the fourth edition is not available, the man page for the ctime(3) library function is:

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man3/ct...

It confirms that the day of the month element was one based. This function is different in earlier editions:

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V3/man/man3/ct...

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man3/ct...

Everything is 0-indexed in C. It is convenient for each day in a month to correspond to it's ordinal position.For example, the Ides of March would be entry 15 in the structure containing data for the month of March. There is no 0-th day in a month so there are extra, unused entries but this is better than continually changing day values at each reference. The months are just a list and so are 0-indexed and dense.

Quintessential illustration of "premature optimization is the root of all evil". A tiny shortcut in non-performance critical formatting code causes 50 years of pain and bugs.

Reply on news.ycombinator.com