Date: Fri, 21 Jan 2005 15:00:50 -0700 (MST) From: Warner Losh <imp@harmony.village.org> To: cswiger@mac.com Cc: current@freebsd.org Subject: Re: Anybody involved with ISO C standardization ? Message-ID: <20050121.150050.74701505.imp@harmony.village.org> In-Reply-To: <41F14659.8040003@mac.com> References: <30924.1106323869@critter.freebsd.dk> <41F14659.8040003@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050121.150050.74701505.imp>