As all Perl programmers (hopefully) know, the year value from a call to Perl's localtime
function is relative to 1900. Wondering why this was, I took a look at the perldoc for localtime, and found this interesting nugget:
All list elements are numeric and come straight out of the C `struct tm'.
Looking then at the C++ reference for the tm struct, I found that the tm_year
member variable is declared as an int
.
Question: Why, then, is the year value relative to 1900 and not simply the full, four-digit year? Is there some historical reason? It seems to me that, even with early memory limitations in computing, an integer is (obviously) more than sufficient for storing the full year. There must have been a good reason; I'm curious as to what that might be.
The localtime() function shall convert the time in seconds since the Epoch pointed to by timer into a broken-down time, expressed as a local time. The function corrects for the timezone and any seasonal time adjustments. Local timezone information is used as though localtime() calls tzset().
The C library function struct tm *localtime(const time_t *timer) uses the time pointed by timer to fill a tm structure with the values that represent the corresponding local time. The value of timer is broken up into the structure tm and expressed in the local time zone.
I was programming in the early 1970's, before C and Unix were invented. Two digit years were used to save disk space which was very very tight, we were always trying to figure tricks like that to save it. The first machine I worked on had two 20 megabyte drives, each the size of a washing machine.
I worked at a hospital that had a Y2K problem in 1975. The age of a patient is an important thing to know, and the date of birth only had a two digit year. Being a hospital, we obviously had some very old patients, born in the 1800's. The system assumed that anyone whose year of birth was 75 or over was born in the 1800's. This worked well for people born in 1890, but once Jan 1, 1975 hit, all heck broke loose as the newborns were deemed to be 100 years old. (It was also a major maternity hospital.) We ran around fixing that problem by moving the threshold from 75 to 80. It was also my first understanding of what a problem Y2K was going to be, and I realized I would be better off doing something else by the year 2000. I failed.
Those who think Y2K was not a real problem because nothing happened do not understand the amount of work that went into fixing stuff for the few years beforehand.
When computers started to keep track of time, the year was referenced only with 2 digits. As for the "why" part, i haven't heard any definite reason, other than "They wouldn't have to worry about that for another 30 years". When clocks got dangerously close to year 2000, and people realized that their code needed to keep track of time after 1999 as well, most software was still using 2 digit years (afterall, having everyone swap to 4 digits would break a lot of code unless 100% swapped). The workaround for dodging the Y2K bug was to make the year a reference to 1900.
It's one of these cases where it coulda shoulda woulda been done right in the first place. (QWERTY keyboard layout was originally designed to be inefficient. Also, the current in an electronic circuit is dictated as going from + to -, while in reality, electrons actually move the opposite way).
This is speculation.
Back when Unix was invented there were machines in use that had 36-bit words, and one popular unpacking of those words was 4 9-bit characters. If tm_year is set to year - 1900, then all the individual struct tm fields would fit into 9-bit unsigned chars. Memory was very tight on those old machines, so packing data tightly into structs was a bigger concern then than it is today.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With