From owner-freebsd-current@FreeBSD.ORG Fri Jan 21 18:18:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 397BF16A4CE for ; Fri, 21 Jan 2005 18:18:11 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C14043D3F for ; Fri, 21 Jan 2005 18:18:10 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0LII96U033042; Fri, 21 Jan 2005 19:18:09 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Chuck Swiger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 21 Jan 2005 13:13:45 EST." <41F14659.8040003@mac.com> Date: Fri, 21 Jan 2005 19:18:09 +0100 Message-ID: <33041.1106331489@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@freebsd.org Subject: Re: Anybody involved with ISO C standardization ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2005 18:18:11 -0000 In message <41F14659.8040003@mac.com>, Chuck Swiger writes: >Poul-Henning Kamp wrote: >> I just read another brain-dead proposal for a new timeformat >> which appearantly is in the ISO C queue and I would really >> like if we can avoid having another damn mistake in that area. >> (http://david.tribble.com/text/c0xlongtime.html) > >I tried to figure out what was wrong with the proposal, and came up with this: > >"The longtime_t type represents a system time as an integral number of ticks >elaped since the beginning of the long time epoch. Each tick is two >nanoseconds in length. The epoch begins at {AD 2001-01-01 00:00:00.000 Z}. > >Long time values represent dates across the range of {AD 1601-01-01 00:00:00 >Z} to {AD 2401-01-01 00:00:00 Z} within the proleptic Gregorian calendar." Lets take just the two worst mistakes: Resolution of 2 nanoseconds. To get seconds you have to do a 64 bit divide by 500000000 ? Anyone here heard about binary computers ? Binary fractions please, that we we can simply shift way the bits we don't want: seconds = longtime >> 29; (For some value of 29.) Optional leap seconds. As if leap seconds are not enough trouble already, the last thing we need to do is to make them optional. Either the seconds are on the UTC timescale, in which case they contain leap seconds, or they are on TAI and don't. The world has plenty of bad homegrown timescales already, we do not need another one. -- 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.