Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
From:	Chris Faylor <cgf AT cygnus DOT com>
Date:	Tue, 11 May 1999 11:59:59 -0400
To:	cygwin AT sourceware DOT cygnus DOT com
Cc:	Mumit Khan <khan AT xraylith DOT wisc DOT edu>
Subject:	Re: B20.1: ftime bug
Message-ID:	<19990511115959.B821@cygnus.com>
References:	<001b01be9b23$b5bb3c60$227196c0 AT dodo DOT seaspace DOT com> <Pine DOT SUN DOT 3 DOT 93 DOT 990510161330 DOT 14165L-100000 AT modi DOT xraylith DOT wisc DOT edu>
Mime-Version:	1.0
X-Mailer:	Mutt 0.95.3i
In-Reply-To:	<Pine.SUN.3.93.990510161330.14165L-100000@modi.xraylith.wisc.edu>; from Mumit Khan on Mon, May 10, 1999 at 04:16:24PM -0500

On Mon, May 10, 1999 at 04:16:24PM -0500, Mumit Khan wrote:
>On Mon, 10 May 1999, Scott Herndon wrote:
>> ftime() is filling the time member of its argument with something other than
>> the number of seconds since the epoch.
>> 
>> time() returns a number close to 926367193 (which seems right) while the
>> time member that ftime() populates is filled with a number like 2949164.
>> gettimeofday() seems to return the same (wrong) value that ftime() does.
>
>gettimeofday and anything else that uses the same backend, eg., ftime, is
>broken in b20.1. Search the mailing list for more info. Good news is that
>it's fixed in recent snapshots, and so you can expect it fixed in b21.
>
>Interestingly enough, I see a 20 second or so lag in Cygwin's time than in
>the native time. Wonder if it's just due to the time taken to process the
>data and so on.

Yow!  I hope it isn't that slow.

Btw, someone just submitted a patch for dealing with daylight savings
time.  I haven't had a chance t evaluate it yet.  I've heard conflicting
reports as to whether there is actually a problem or not.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -