From owner-freebsd-current@FreeBSD.ORG Fri Jan 21 22:03:26 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 EA4C416A4CE for ; Fri, 21 Jan 2005 22:03:26 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43EE243D2F for ; Fri, 21 Jan 2005 22:03:26 +0000 (GMT) (envelope-from imp@harmony.village.org) Received: from localhost (localhost [IPv6:::1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j0LM0oB4048734; Fri, 21 Jan 2005 15:00:50 -0700 (MST) (envelope-from imp@harmony.village.org) Date: Fri, 21 Jan 2005 15:00:50 -0700 (MST) Message-Id: <20050121.150050.74701505.imp@harmony.village.org> To: cswiger@mac.com From: Warner Losh In-Reply-To: <41F14659.8040003@mac.com> References: <30924.1106323869@critter.freebsd.dk> <41F14659.8040003@mac.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 22 Jan 2005 12:44:14 +0000 cc: phk@phk.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 22:03:27 -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. :-) ] There's problems with leap seconds too. Sometimes they are swizzled in, and sometimes not. The #define is confusingly backwards. There's no provision for knowing if you have leap seconds or not. There's a cavalier attitude towards them. They say you don't normally need them, but if you want to know the actual elapsed time you do (think what happens over a leap second where time replays). There's no way to convert from internal to external to internal again (because the external represenation, whatever that means, maps positive leap seconds to the same value). It is a complete trainwreck. Warner