Когда-то компьютеры программисты не умели нормально считать, и предпочитали битмаски нетривиальным вычислениям.
В MSDOS FAT дата упаковывалась в 16 бит YYYYYYYMMMMDDDDD где YYY=год-1980, MMM=месяц, DDD=день.
Всё было бы хорошо до 2127 года, но вместо 1980+YYY многие ещё немного экономили и писали "19" 80+YYY , то есть даты на выходе получались, в зависимости от криворукости, 19100 или 1900

Ну когда на ассемблере пишешь, может быть чуть короче. Говнокодеры существовали и 30 лет назад

Кстати, на проблему 2037 года кто-то наступил уже в 2006 - они для получения "даты из будущего" прибавляли миллиард секунд у текущему времени

Если честно, 19100 не встречал, но 1900 сколько угодно, и 19:0 видел

Так я не понимаю что это за экономия такая, когда дату хранят как строку? Минимальный формат даты в таком виде (yymmdd) занимает шесть (!) байт, тогда как в четыре влезает количество секунд (!) до 2038 года.

Кроме экономии места нужно было экономить вычисления. В 60-е гг., когда этот формат хранения даты укоренился в Коболе, реально думали, сколько лишних тактов понадобится для того или другого. И были сильны сторонники ассемблера, которые считали, что языки высокого уровня вообще не нужны, потому что тратят слишком много машинных ресурсов. Библиотеки тоже только начали появляться, а значит, как правило, всё, что не было встроено в язык, должно было быть написано с нуля в каждом новом проекте. Включая перевод даты в текст для отображения.

Я гораздо больше боюсь проблемы 2038 раз уж на то пошло. Потому что хранить дату в юникс тайме это правда стандарт местами до сих пор.

time_t уже везде 64-битный, так что проблема 2038 года будет актуальна или на каких-то очень старых системах, или в говнокоде.

Binary coded decimal это отдельный маленький адок, достойный своей статьи. Я удивляюсь, какой сон менеджерского разума породил это чудовище, и как оно было популярно пару десятков лет

Ну я так понимаю, с перфокарты человеку легко прочитать такое число без произведения особых вычислений, просто помня двоичные репрезентации десяти цифр.

А кроме того

BCD is very common in electronic systems where a numeric value is to be displayed, especially in systems consisting solely of digital logic, and not containing a microprocessor. By employing BCD, the manipulation of numerical data for display can be greatly simplified by treating each digit as a separate single sub-circuit. This matches much more closely the physical reality of display hardware—a designer might choose to use a series of separate identical seven-segment displays to build a metering circuit, for example. If the numeric quantity were stored and manipulated as pure binary, interfacing with such a display would require complex circuitry. Therefore, in cases where the calculations are relatively simple, working throughout with BCD can lead to an overall simpler system than converting to and from binary. Most pocket calculators do all their calculations in BCD.

The same argument applies when hardware of this type uses an embedded microcontroller or other small processor. Often, representing numbers internally in BCD format results in smaller code, since a conversion from or to binary representation can be expensive on such limited processors. For these applications, some small processors feature dedicated arithmetic modes, which assist when writing routines that manipulate BCD quantities.

Представление на перфокарте это даже проще, чем EBCDIC - цифра это одна дырочка на соответствующем месте

Ну это самый удобочитаемый вариант, а были и "бинарные" (люди хотели втискивать в перфокарты больше информации).