php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #1281 microtime() doesn't work in Win32-version
Submitted: 1999-04-01 10:45 UTC Modified: 1999-09-21 04:24 UTC
From: markus dot laire at usa dot net Assigned:
Status: Closed Package: Misbehaving function
PHP Version: 3.0.6 OS: Win95
Private report: No CVE-ID: None
 [1999-04-01 10:45 UTC] markus dot laire at usa dot net
I just copied Win32-version of PHP 3.0.6 files to the directory without any other configurations.

Following is message I send to the php3-list about 
"[PHP3] Differences in win32 and linux versions"


> start = 135.87952200 922643904 - end = 136.02899400 922643904
> 
> Does this mean that it only took 136.03 - 135.88 = .15 milliseconds to
> execute the db stuff? I am not quit sure what the "msec" part of the
> microtime() function represents.

That means it took _about_ (nowhere near exactly - see below) 
0.15 seconds to execute that.

I tested differences in win32 and linux by running following script 
with win32-version of PHP in my Win95-computer and also in my 
homepage at linux-server.

<?php
for ($x = 0; $x < 10000; $x++) {
  usleep(1000); // sleep 1/1000 seconds = 1 millisecond
                      // so that this script won't execute too fast
  echo microtime(), ' ', time(), ' ', date("U H:i:s"), "\n<BR>";
}
?>

With Linux, script printed

0.5xxxxxxx 922695800 922695800 922695800 11:23:20
0.5xxxxxxx 922695800 922695800 922695800 11:23:20
0.5xxxxxxx 922695800 922695800 922695800 11:23:20
..
0.9xxxxxxx 922695800 922695800 922695800 11:23:20
0.0xxxxxxx 922695801 922695801 922695801 11:23:21
..
0.9xxxxxxx 922695801 922695801 922695801 11:23:21
0.0xxxxxxx 922695802 922695802 922695802 11:23:22
..
This is just what I expected script should print.
So, msec part is always between 0.0 and 1.0, and you can get real 
time simply by calculating $msec_part + $sec_part

But, when run with Win32, this isn't so simple:
With Win32, script printed:

216.5xxxxxxx 922695800 922695800 922695800 11:23:20
216.5xxxxxxx 922695800 922695800 922695800 11:23:20
216.5xxxxxxx 922695800 922695800 922695800 11:23:20
..
216.94920900 922695800 922695800 922695800 11:23:20
216.95155400 922695801 922695801 922695801 11:23:21
..
216.99951800 922695801 922695801 922695801 11:23:21
217.00153500 922695801 922695801 922695801 11:23:21
..
217.94497400 922695801 922695801 922695801 11:23:21
217.94760700 922695802 922695802 922695802 11:23:22
..
217.99750800 922695802 922695802 922695802 11:23:22
218.00003600 922695802 922695802 922695802 11:23:22
..
First, msec part isn't between 0.0 and 1.0 and when you use it, 
you must first discard integer part of it and only take fraction part 
which is between 0.0 and 1.0.
Much more important thing is, that msec part and sec part are 
NOT synchronized and so you can't get real time by calculating 
$fraction_of_msec_part + $sec_part
This is about the real time, but not exactly.
This script run about 23 seconds and below are start and end 
times:

216.94920900 922695800 922695800 922695800 11:23:20
216.95155400 922695801 922695801 922695801 11:23:21 <- start
..
237.97241700 922695822 922695822 922695822 11:23:42
237.97522000 922695822 922695823 922695823 11:23:43 <- end

sec part difference: end-start = 43-21 = 22
msec part difference: end-start = 237.97522000-216.95155400 = 21.023666
accuracy is about 22sec/10000 = 0.0022secs

21.02 / 22 = 95.5%

So, when sec-part goes up by one, msec-part goes up - not by one 
- but by about 0.955. These two times increases with diffferent 
speed and because that, they aren't synchronized.



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1999-09-21 04:24 UTC] sas at cvs dot php dot net
The integer part is now always set to 0.
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved.
Last updated: Fri Jul 10 02:00:01 2026 UTC