From owner-freebsd-current@FreeBSD.ORG Fri Jan 21 18:12:09 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 7440616A4CE for ; Fri, 21 Jan 2005 18:12:09 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09F1043D53 for ; Fri, 21 Jan 2005 18:12:09 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] (pool-68-160-236-186.ny325.east.verizon.net [68.160.236.186]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id j0LIC2H1068105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2005 13:12:04 -0500 (EST) Message-ID: <41F14659.8040003@mac.com> Date: Fri, 21 Jan 2005 13:13:45 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <30924.1106323869@critter.freebsd.dk> In-Reply-To: <30924.1106323869@critter.freebsd.dk> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.9 required=5.5 tests=AWL,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=disabled version=3.0.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on pi.codefab.com 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:12:09 -0000 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." [ Ugh. :-) ] -- -Chuck