Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.sources.wanted
Subject: Re: Timestamp
Message-ID: <13100@bloom-beacon.MIT.EDU>
Date: 29 Jul 89 02:32:22 GMT
References: <1595@stl.stc.co.uk> <12687@bloom-beacon.MIT.EDU> <2247@auspex.auspex.com>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 45

In article <2247@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>A somewhat standard but little-known routine already
>>exists which provides what you want: ftime().
>1) "somewhat standard" is the key word here.  In the UNIX world, it's in V7,
>   and in 4.xBSD, but not in System V.

What a miserable pity.  No wonder it's not in POSIX.

>>It returns a structure which "contains the time since the epoch in seconds,
>>[and] up to 1000 milliseconds of more-precise interval."
>2) "more precise" doesn't necessarily mean "precise down to the
>   millisecond"; it will probably reflect the resolution of the OSes
>   clock, which is may well be closer to 10 milliseconds than one
>   millisecond.

Indeed.  Given, however, that it is documented and understood
that, in effect, the LSB's of the millitm field (the
"more-precise interval") do not necessarily wiggle, it is
extremely unfortunate that such a function is not standard.  (Why
in the world did SYSV drop ftime?)  Subsecond timing is important
for many programs, and there's no other way to get it.  I don't
mind it when superfluous system calls are deleted in the
interests of streamlining or standardization, but ftime (or the
equivalent) is irreplaceable.

I submit that any vendor (that can support POSIX) can supply
ftime.  Given that the time() function is required, write ftime
(at the very least) as:

	ftime(tp)
	struct timeb *tp;
	{
	tp->time = time((time_t)0);
	tp->millitm = 0;
	return 0;
	}

(this ignores the timezone and DST stuff).  My point is not that
this is a good implementation (it isn't), but that it is an
acceptable one, and therefore that "some systems couldn't
implement it" is not an adequate reason for leaving ftime out of
standards.

                                            Steve Summit
                                            scs@adam.pika.mit.edu