3 ms·

https://github.com/ufuu/JDK10/blob/main/src/src/java/util/Date.java https://github.com/ufuu/JDK10/blob/main/src/src/java/util/Da... > private int tm_year; /* y

by trias 5y ago

https://github.com/ufuu/JDK10/blob/main/src/src/java/util/Date.java 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.

vbezhenar 5y ago
int is signed.
- rzzzt 5y ago
  You don't want to go back 2 billion years from 1900?
- froh 5y ago
  on x86 and arm. not on s390.
  - rzzzt 5y ago
    In a Java Virtual Machine, it is a 32-bit signed value: https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.3.1 https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.ht...
    - froh 5y ago
      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.
- im3w1l 5y ago
  It would be possible and kind of hilarious to use a negative offset from year 2b.
formerly_proven 5y ago
That's a verbatim copy of struct tm from C.
quickthrower2 5y ago
Sounds like downright pragmatism
slver 5y ago
Think about it.
- slver 5y ago
  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.
deleted 5y ago
[deleted]

by trias 5y ago

vbezhenar 5y ago

int is signed.

rzzzt 5y ago
You don't want to go back 2 billion years from 1900?
froh 5y ago
on x86 and arm. not on s390.
- rzzzt 5y ago
  In a Java Virtual Machine, it is a 32-bit signed value: https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.3.1 https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.ht...
  - froh 5y ago
    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.
im3w1l 5y ago
It would be possible and kind of hilarious to use a negative offset from year 2b.

formerly_proven 5y ago

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

quickthrower2 5y ago

Sounds like downright pragmatism

slver 5y ago

Think about it.

slver 5y ago
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.

deleted 5y ago

[deleted]