From owner-freebsd-arch Sat Jun 2 23:40:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id DA19B37B422 for ; Sat, 2 Jun 2001 23:40:20 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f536e8144561; Sun, 3 Jun 2001 08:40:08 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Erik Trulsson Cc: arch@FreeBSD.ORG Subject: Re: time_t definition is worng In-Reply-To: Your message of "Sat, 02 Jun 2001 22:26:27 +0200." <20010602222626.A26556@student.uu.se> Date: Sun, 03 Jun 2001 08:40:08 +0200 Message-ID: <44559.991550408@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010602222626.A26556@student.uu.se>, Erik Trulsson writes: >My take on the situation is as follows: > >While it will be necessary to make time_t a 64-bit type eventually to >avoid wrap-around in 2038 I am afraid that this will break many >programs and will require quite a bit of work to fix all problems. >(Yes, it is the Y2K problem all over but with another breakage-date.) > >So until everybody is prepared to make that change it is probably a >good idea to continue having time_t as a 32-bit type. Bad choice. There will never be a time where "everybody is prepared". Instead lets set a deadline: The longest commonly used time interval is 30 years for mortgages, so lets be safe and say that on january 1st 2005 00:00 UTC we will transition time_t to be at least 33 bits. Until then it is 32 bits. In practice this will probably be 64 bits on most arch's but let us use the 33 bit goal rather than mandate 64bits which might be prohibitively expensive on some architecturs. Any objections ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message