On Thu, 28 Dec 2017 00:19:20 -0700 Brian Cluff wrote: > How many bits that are used for time has little to do with how many > bits the processor has.  There is still plenty of software that has > their time hard coded to use 32bits even if it's running on a 64bit > processor. Who would do that? Almost everywhere, as far as I know, time is a long int. With 32 bits, a long int with every second since 1/1/1970 expires in 2038. But a 64 long int goes out to a point in time when we'll probably have self-destructed our species anyway. I know a lot of Cobol programs defined a date as pic999999 and that's a problem regardless of int size. But presumably for y2k they increased that to pic99999999, and that's good til New Years Eve 9999. > It's seems like it's not so much the desktops and servers > we have to worry about, but all the 32 bit embedded systems, old file > formats and things like buildings and cars that tend to get stuck > with whatever they were deployed with, that are going to hurt us. > > https://lwn.net/Articles/717076/ > > I don't think it's going to be a big deal though... but who knows, we > could be in for a surprise. Cars are a problem. We all expect our 60 year old 1957 Chevies to keep running. In 2038 a 60 year old car will be a 1978: Not an unreasonable expectation. By 2038 they can gain 29 years by redefining epoch-start as 1999 instead of 1970. By 2067 technology will be so advanced that there can be special hobbiest car computer simulators that do all the same stuff as the original equipment, but have 64 bits underneath, and do dates the right way. SteveT Steve Litt December 2017 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org To subscribe, unsubscribe, or to change your mail settings: http://lists.phxlinux.org/mailman/listinfo/plug-discuss