[trias]

https://github.com/ufuu/JDK10/blob/main/src/src/java/util/Da...

> private int tm_year; /* years since 1900 */

when you have 4.3 billion years to choose from but decide for 1900.

[formerly_proven]

That's a verbatim copy of struct tm from C.

[quickthrower2]

Sounds like downright pragmatism

[vbezhenar]

int is signed.

[im3w1l]

It would be possible and kind of hilarious to use a negative offset from year 2b.

[rzzzt]

You don't want to go back 2 billion years from 1900?

[froh]

on x86 and arm. not on s390.

[rzzzt]

In a Java Virtual Machine, it is a 32-bit signed value: https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.ht...

[froh]

my bad you're right. I got confused on if we are on the java or on the c side of things, because we discussed 'verbatim copy of c struct... fields'

apologies.

[slver]

Think about it.

[slver]

Judging from the downvotes, a good portion failed at thinking about it. Answer:

In the 20th century, we commonly expressed the year by its last two digits, you know this is why we talk about "70s", "80s", "90s". It's a small number, not ambiguous, and it also happens to be "the number of years since 1900". So of course a computer in the mid to late 20th century would choose this base. IT means the number is convenient for display, but also works for the machine, because "years base 1900" is a valid machine model as well. And it became a popular time format others picked up.

Lo and behold, though, the world didn't end in 2000. What do we do? Well, let it go over 99 and we add "1900" to it for display purposes, so we can maintain BC.

There. That's why we didn't choose any other base from 4.3 billion years or whatever.