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 Message-ID: <37384E57.8FA93F8@swi.com> Date: Tue, 11 May 1999 11:35:51 -0400 From: Paul Berrevoets Organization: SWI Systemware/Halcyon Inc. X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: cygwin-list Subject: Re: B20.1: ftime bug References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mumit Khan wrote: > 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. No. I submitted this bug to cygwin: The gettimeofday() function returns wrong struct timeval values. The sample code below will show that the current time returned by time() and gettimeofday() differ by a number of seconds (depending on which timezone you are in). In looking at the source code for gettimeofday(), the function should NOT adjust for the timezone. In winsup/times.cc::gettimeofday() change: 124: totimeval (p, &f, tz.Bias * 60, 1); to 124: totimeval (p, &f, 0, 1); Additionally, totimeval() does not adjust for timezone correctly even if it were given one. In winsup/times.cc::totimeval() change: 96: x -= (long long) sub * CLOCKS_PER_SEC; to 96: x -= (long long) sub * (int) (1e6); Sample Code: #include #include int main() { struct timeval tv; int rc = gettimeofday(&tv, 0); printf("%d %d.%06d=%d\n", time(0), tv.tv_sec, tv.tv_usec, rc); return 0; } Solaris result: solaris> ./a.out 925251283 925251283.777141=0 Windows result: bash-2.02$ ./a.exe 925251304 925251275.656000=0 -- Paul -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com