Topic: EuroBlitz graph times solution

[dfroula]

I believe I have solved the issue with the old EuroBlitz script showing the wrong times on the hourly summary graph, at least in my installation.

The hourly graph labels are calculated from the "graphtimes" array in your cache/bo.tx file. I noticed that this array was filled with negative numbers, which did not seem right.

I looked in the bo_update.php script and found the code block responsible for generating the array:

Code: [Select]

# GRAPH
date_default_timezone_set($localtimezone);
$utcdiff = date("Z");
date_default_timezone_set("UTC");
$q = mysql_query("SELECT * FROM `$db`.`bo_hourly` WHERE time > '".($timestamp-86400)."' ORDER BY time DESC");
while ($m = mysql_fetch_array($q, MYSQL_BOTH)) {
  $graph[] = floatval($m[strikes]);
  $graphtimes[] = intval(($utcdiff + $m[time])*1000);
}
Note the second to last line:

$graphtimes[] = intval(($utcdiff + $m[time])*1000);

The code is using the "intval" functions to cast each adjusted UTC timestamp in the bo_hourly table of the database as an "int". However, the "intval" function returns a signed integer, which in my case was negative. php does not support unsigned integers directly.

The 'intval" function call was the culprit that was producing the negative signed integers.

I removed the "intval" call, and the graph began displaying the correct times after the cron job updated the bo.txt file after a minute or so.

To get local hourly times to show correctly I needed to set "date_default_timezone_set("CDT");" and "$localtimezone="CDT";" in bo_update.php (my local time zone). If I did not do that, the time offset calculation in the above code block was returning "0", resulting in UTC hourly time stamps in the graph.

I also set "date_default_timezone_set("CDT");" in the bo.php script (my local time zone).

I don't know if the "intval" issue is a 32-bit vs. 64-bit issue or due to some peculiarity on my server.

Check your cache/bo.tx file. If the "graphtimes" array at the end of the file is showing negative values, try replacing the above code block with the following and adjust all the time zone definitions I mentioned with your local time zone. Delete the bo.txt file and wait for your cron job to refresh bo.txt. Verify the negative numbers are gone. Refresh the page with your script display, and the hourly stamps should correctly show the local hour. No need to clear the database tables.

Code: [Select]

# GRAPH
date_default_timezone_set($localtimezone);
$utcdiff = date("Z");
date_default_timezone_set("UTC");
$q = mysql_query("SELECT * FROM `$db`.`bo_hourly` WHERE time > '".($timestamp-86400)."' ORDER BY time DESC");
while ($m = mysql_fetch_array($q, MYSQL_BOTH)) {
  $graph[] = floatval($m[strikes]);
#  $graphtimes[] = intval(($utcdiff + $m[time])*1000);
  $graphtimes[] = (($utcdiff + $m[time])*1000);
}
Regards,

Don

[dfroula]

OK, another little "gotcha"....

The GRAPH code does not correctly calculate the time offset if I have bo_update.php configured with "$localtimezone="CDT";".

However it DOES calculate it correctly if  bo_update.php is configured with "$localtimezone="America/Chicago";".

Therefore, the correct values of time zone to set for me are:

bo_update.php
=========
date_default_timezone_set("UTC");
$localtimezone="America/Chicago";

bo.php
====
date_default_timezone_set("UTC");

With the "intval" fix I mentioned (if you see negative values in the graphtimes array in bo.txt), all works as it should.

Note the use of the "intval" function in bo_update.php's calculation of the $stmaxdist and $stmindist statistics variables works fine. I think there may be some overflow issue when "intval" is applied to a Linux time string, especially since the code multiplies the timestamp by 1000 within the "intval" function.

Don

[dfroula]

This web page explains the "intval" problem:

http://stackoverflow.com/questions/21066249/php-intval-returning-something-unexpected

"The size of an integer in PHP is platform-dependent. The documentation for intval() clearly explains this:

The maximum value depends on the system. 32 bit systems have a maximum signed integer range of -2147483648 to 2147483647. So for example on such a system, intval('1000000000000') will return 2147483647. The maximum signed integer value for 64 bit systems is 9223372036854775807."

Don

[dfroula]

I was unaware, but PHP uses a different list of valid timezone names than the tz database on the hosting Linux server! I saw at least one posting where the Linux tz database name did not work in the php scripts. In that case, Henekka's script reverts to UTC.

The complete list of valid PHP timezones is at:

http://www.php.net/manual/en/timezones.php

 Best,

 Don