Date: Tue, 20 Apr 1999 11:50:30 +1000 From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> To: chad@DCFinc.com, stephen@math.missouri.edu Cc: stable@FreeBSD.ORG Subject: Re: Year 2000 Message-ID: <99Apr20.113653est.40407@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
Stephen Montgomery-Smith <stephen@math.missouri.edu> wrote: >While we are on the subject, as I understand it, UNIX has a year 2038 >problem coming up. Dates after 2038/01/19 03:14:07 UTC can't be represented as a signed 32-bit number. > After we get through the Y2K hurdle, shouldn't we >start to seriously tackle the year 2038 problem? This issue was discussed at length on -hackers in mid-August last year, and in -current at the beginning of January this year. (Without any conclusion being reached). The simple options are basically to change time_t to a 32-bit unsigned int (postponing the problem to early 2106), or a 64-bit int (postponing the problem by 250-500e9 years). The decision is basically which choice will break less software. (Another option is to make time_t 64-bits, but count smaller intervals - eg 1/65536 sec - which helps UFS timestamps). There are also a range of other similar events around then: MS-DOS wraps around 2036 (from memory), IBM mainframes wrap in 2040 (although I believe IBM has changed the epoch to postpone this). The RISKS archives have other examples. >Just wondering if the internet will face serious problems in 2038 >because of all the `old' unix software still running it. The `time' service (port 37) is defined using a 32-bit integer time. I suspect there are other network protocols that will have problems adjusting to a change in time_t. "Chad R. Larson" <chad@DCFinc.com> wrote: >I believe the assumption is that within 30 years, UNIXs will have >moved time_t from a "long" to a "long long" (or "quad" or whatever). >Most the commercial vendors (HP-UX, Solaris) have already done this as >part of their 64-bit UNIX initiatives. Just to be different, Digital UNIX changed time_t from long to int so that it didn't change to 64-bits on the Alpha :-(. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Apr20.113653est.40407>