From owner-freebsd-stable Mon Apr 19 18:53:42 1999 Delivered-To: freebsd-stable@freebsd.org Received: from alcanet.com.au (news.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 4708F1563C for ; Mon, 19 Apr 1999 18:53:13 -0700 (PDT) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40407>; Tue, 20 Apr 1999 11:36:53 +1000 Date: Tue, 20 Apr 1999 11:50:30 +1000 From: Peter Jeremy Subject: Re: Year 2000 To: chad@DCFinc.com, stephen@math.missouri.edu Cc: stable@FreeBSD.ORG Message-Id: <99Apr20.113653est.40407@border.alcanet.com.au> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Stephen Montgomery-Smith 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" 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