Y2K

[Steve Litt]

On Thu, 28 Dec 2017 00:19:20 -0700
Brian Cluff <brian at snaptek.com> 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