Kees.Dekker@infor.com said: | I don?t understand how 32-bit time_t systems can survive 2038 There are proposals (even implemented, though I am not sure how widely) to alter the range of 32 bit time_t, 0 is still Jan 1, 1970, but from that positive values range from (say) 1..BFFFFFFF and C0000000..FFFFFFFF are negative. (The actual cutover point seems to vary). That one would extend the usefulness of 32 bit time_t values until 2072 (or perhaps beyond, depending upon the switch point) and limiting the earliest value to 1936 (or whatever) isn't likely to seriously bother anyone. If the switch point were F0000000 (so EFFFFFFF is the biggest positive value) the range of timestamps would be from mid 1961 to mid 2097, which would probably be OK, and gives lots of time for everything to be converted. Note that processing isn't the issue (the 32 bit time_t values can be moved to 64 bit variables, represented as regular 2's complement binary numbers, for that), but converting all the places that time_t's get stored is hard. Certainly everything new should really be using 64 bit values by now. NetBSD was (I believe) one of the earliest systems to switch to a 64 bit time_t (years ago now) - yet we still have to support people with filesystems created even longer ago, that still have only 32 bit spaces for the seconds part of the timestamps, and which are still in use (new/updated timestamps being created every day.) There is also lots of old application code around, some in binary only form, which has to keep running, and in that, time_t would have been 32 bits. How much of that will still be a problem in another 20 years, when expiry of a current format 32 bit time_t is imminent, I have no idea. But just switching time_t to 64 bits doesn't solve all the problems by itself. kre