Anybody involved with ISO C standardization ?

[Poul-Henning Kamp]

In message <41F14659.8040003 at 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 at 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.