Date: Fri, 21 Jan 2005 19:18:09 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Chuck Swiger <cswiger@mac.com> Cc: current@freebsd.org Subject: Re: Anybody involved with ISO C standardization ? Message-ID: <33041.1106331489@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 21 Jan 2005 13:13:45 EST." <41F14659.8040003@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33041.1106331489>