Hi, I have built embedded systems that have run 20 years with no update - but I doubt they are common.
More of an issue is archived data. I have read data 30 years old, and may well do so again. While I think the answer is "human readable date formats" The Americans have scuppered that with M-D-Y. I am sure there will still be 32 bit systems in 30 years time - there will still be 8-bit systems too. In summary: 1) 64 bit dates are needed ASAP, even on 8 bit machines. 2) What has Linux got to do with the price of fish? Andrew On 11 July 2017 at 11:23, Stuart Henderson <s...@spacehopper.org> wrote: > On 2017/07/11 01:55, Kyle J. McKay wrote: > > 2) 32-bit systems are going to be around for many years still; 32-bit ARM > > platforms are everywhere > .. > > 4) 32-bit time_t has potentially still got over 20 years of life left in > it > > Yes. The gamble is whether 32-bit systems will still be around then. > I don't see why they _wouldn't_ be. The sooner that OS adapt, the less > likely there are to still be operational systems when 2038 comes around. > > > 3) 32-bit systems typically have 32-bit time_t values (I'm not aware of > > anything in the standard preventing use of a 64-bit time_t on a 32-bit > > system but that doesn't seem to be happening, at least not yet) > > This depends on the OS. Linux's general avoidance of ABI breaks is > certainly a problem in this area. NetBSD has used 64-bit time_t on all > architectures since 6.0 (2012) and OpenBSD since 5.5 (2014). I haven't > looked recently but IIRC FreeBSD has 64-bit time_t on 32-bit ARM > (and of course on 64-bit systems). > > Plenty of software still needs patching to fix operation on a 32-bit > arch with 64-bit time_t - we have a lot of these in the ports tree > (with mixed success feeding such changes upstream - "Linux doesn't > need it"...). > >
