Dave Rahardja on Nostr: nprofile1q…f3t7p To represent a date, UNIX systems traditionally use a signed ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqdg499t2jtuunfjnqtc4flhvv48w05m3ujczxuy8enr9vcxd9mqsqwf3t7p (nprofile…3t7p) To represent a date, UNIX systems traditionally use a signed 32-bit integer that counts the number of seconds since 0 GMT, January 1, 1970 (in both positive and negative directions). In 2038, we will run out of positive seconds, and dates will “wrap around” to 1901, the same way that “00” means “1900” instead of “2000” during Y2K.
Is this a problem? Probably not in any real way. Most UNIX-based PCs and compute hardware have moved from 32-bit to 64-bit CPUs, and the underlying date type (time_t) was simultaneously upgraded to 64 bits, which has a max range of 292 billion years, i.e. long after the earth is gone.
This is then only a problem for lower-cost, 32-bit hardware that use older software that can’t be updated (even 32-bit Embedded Linux now uses 64-bit date types). There may be some appliances that think it’s 1901 at some point, but will it matter in a practical way? I doubt it.
Any critical software would be audited and tested years before the date as well, so I wouldn’t worry.
Is this a problem? Probably not in any real way. Most UNIX-based PCs and compute hardware have moved from 32-bit to 64-bit CPUs, and the underlying date type (time_t) was simultaneously upgraded to 64 bits, which has a max range of 292 billion years, i.e. long after the earth is gone.
This is then only a problem for lower-cost, 32-bit hardware that use older software that can’t be updated (even 32-bit Embedded Linux now uses 64-bit date types). There may be some appliances that think it’s 1901 at some point, but will it matter in a practical way? I doubt it.
Any critical software would be audited and tested years before the date as well, so I wouldn’t worry.