The move to a 64-bit is sufficient, or at least a 64-bit time_t suffices for the very foreseeable future. Adding just one byte doesn't gain you much because nei

The move to a 64-bit is sufficient, or at least a 64-bit time_t suffices for the very foreseeable future. Adding just one byte doesn't gain you much because neither CPUs, nor most programming languages deal well with a 36-bit type – you'd end up with a 64-bit type anyway in most cases which is nicer to handle. The question probably is why a 32-bit type was deemed sufficient back then, but as others have noted, it is very hard to anticipate the lifetime of software and it was a pragmatic tradeoff between anticipated OS lifetime and necessary storage space. There are other problems as well, though. time_t is a type designed for keeping track of the current time of a computer system, therefore an arbitrary cutoff point in the past is sufficient. But then it got used for all kinds of other things – storing people's birthdays, using it as internal representation for a DateTime type, etc. Those have been problematic ever since because a possible date range of 1901–2038 is not necessarily sufficient for those use cases. Fact is, though, that for keeping time in a computer a simple scalar that counts units since a reference date is the easiest and most efficient solution. Over time there have been plenty of such reference dates (epochs) [½], the most notable these days probably Unix (1970-01-01), popular spreadsheets (around 1900-01-01) or Windows (1601-01-01). [½] http://en.wikipedia.org/wiki/Epoch_(reference_date)#Notable_epoch_dates_in_computing http://en.wikipedia.org/wiki/Epoch_(reference_date)#Notable_...