From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 13 16:22:15 2008 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07EF716A417 for ; Sun, 13 Jan 2008 16:22:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9E57C13C44B for ; Sun, 13 Jan 2008 16:22:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m0D8favL010551 for ; Sun, 13 Jan 2008 19:41:36 +1100 Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m0D8fW7g002024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Jan 2008 19:41:33 +1100 Date: Sun, 13 Jan 2008 19:41:32 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Peter Jeremy In-Reply-To: <200801130550.m0D5o4CL084666@freefall.freebsd.org> Message-ID: <20080113180120.Y5136@besplex.bde.org> References: <200801130550.m0D5o4CL084666@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64/119591: [amd64] [patch] time_t on 64-bit architecture X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2008 16:22:15 -0000 On Sun, 13 Jan 2008, Peter Jeremy wrote: > Whilst I agree that the existing LEAPYEAR macro can only handle > dates between 1901 and 2099, this macro is only used to convert > timestamps to/from the RTC - and currently that code will only > support dates between 1970 and 2069. Anyway, this code should be replaced by merging from the i386 version (after fixing style bugs in that). The i386 version used to be identical with the amd64 versioni, but the i386 version now uses somewhat over-engineered generic code (kern/subr_clock.c) that has different problems in this area: It rejects years > 2037 and is broken for years before 1970 or 1906 (at least with 32-bit time_t's), but its leapyear() function pretends to support the much larger range of 32-bit ints which it cannot possibly support in full. There has to be a range check for the limited range that can be supported, and it may as well be for 1901-2099 or 1906-2037 or 1970-2037 or even 2000-2037 so that everything can be simpler. > There is provision to > separately store the century in the RTC but this code is not > currently active. Better remove it in case it is used :-). It was negatively useful even at the Y2K boundary since the heuristic for determining the century works better except across > 100-year intervals which no one cares about. i386 has lost the heuristic so it can't even go back to 1999. > Note that the code to write the time back to the RTC currently > steps year-by-year and is therefore also needs a rethink before > the range is massively increased. inittodr() also loops on the year. So does clock_ct_to_ts(). This is a good method for a small range of years. Bruce