PhpGedView date warning

This seems to only be an issue if I run PhpGedView from VirtualMin, I get a date warnings:

You are required to use the date.timezone setting or the date_default_timezone_set() function.

Which I know all to well, fixed it by adding in the default date time zone to php.ini under [Date], but that only fixed half the warnings, which is very strange in itself, I add code to try to force it, like:

date_default_timezone_set(‘America/Los_Angeles’);
error_reporting(0);

and this did not help; note that I set error_reporting off, so I should not see any errors, but I still do, which is very strange behavior.

If I log in the warnings go away.

This is on CentOS 6.4

Now to get stranger, I was going to move this app from a sub domain of:
http://family.fleshmaster.org/
to
http://fleshmaster.org/
and it looks like the later is still using the code from the former, and I check the config files, its using a different database, and there is no code that hard codes the path.

Note both sites reference same code in sub domain:

We selected ‘America/New_York’ for ‘EDT/-4.0/DST’ instead in /home/fleshmaster/domains/family.fleshmaster.org/public_html/includes/authentication.php on line 310

So now I have two issues.

My question is, is there another php.ini for cli?
What else could cause this?
locate php.ini did not show any that I missed.

and what would cause this cross domain problem?

Php Info, note bottom of page I added some code to read the php.ini at run time:
http://fleshmaster.org/phpinfo.php
http://family.fleshmaster.org/phpinfo.php

phpinfo();

    
phpinfo();
    
function error_level_tostring($intval, $separator)
{
    $errorlevels = array(
        2047 => 'E_ALL',
        1024 => 'E_USER_NOTICE',
        512 => 'E_USER_WARNING',
        256 => 'E_USER_ERROR',
        128 => 'E_COMPILE_WARNING',
        64 => 'E_COMPILE_ERROR',
        32 => 'E_CORE_WARNING',
        16 => 'E_CORE_ERROR',
        8 => 'E_NOTICE',
        4 => 'E_PARSE',
        2 => 'E_WARNING',
        1 => 'E_ERROR');
    $result = '';
    foreach($errorlevels as $number => $name)
    {
        if (($intval & $number) == $number) 
        {
            $result .= ($result != '' ? $separator : '').$name .'
'; } } return $result; } if (date_default_timezone_get()) { echo 'date_default_timezone_get: ' . date_default_timezone_get() . '
'; } echo "
"; if (ini_get('date.timezone')) { echo 'date.timezone: ' . ini_get('date.timezone') . '
'; } echo "
"; if (ini_get('error_reporting')) { $er=ini_get('error_reporting'); echo 'error_reporting: ' . $er . '
'; echo error_level_tostring($er, ' '); } else { echo 'error_reporting: Off
'; } echo "
"; if (ini_get('display_errors')) { $er=ini_get('display_errors'); echo 'display_errors: ' . ini_get('display_errors') . '
'; } else { echo 'display_errors: Off
'; } echo "
"; echo 'Date: ' . date('l jS \of F Y h:i:s A') . '
';

I have edited the above info, unfortunately those who looked at it the first time, may not look at it again, but I am stuck, the question that bothers me the most is why the domain runs the code from the sub-domain family. maybe its a problem in the code, because it works fine if I do not use Virtualmin (VM), so its hard to ask them, since it doesn't seem to be an issue with their code, at least I can not find fault in it, nor can I find fault with VM, since it appears to be working fine from the phpinfo.php file I uploaded to both folders, in fact that code works the way I would expect it to, but not PhpGedView (http://www.phpgedview.net/), its been stable for the last year, and is a great Family Tree software, the best from what I have used, but clearly something is going on here.

If I remove the Location from the Date in the php.ini, the top half of the default page gives me a warning, so the header and GEDCOM Statistics part of the page does not load, so clearly adding it in fixes that, as you would think it should, the second half of the page seems to be running from the sub-domain, in both URLs, and VM setup the config correctly

Note: I attached the files, it seems mark up is changing things inside the code tags.

fleshmaster.org

SuexecUserGroup “#533” “#509
ServerName fleshmaster.org
ServerAlias www.fleshmaster.org beta.fleshmaster.org media.fleshmaster.org webmail.fleshmaster.org admin.fleshmaster.org
DocumentRoot /home/fleshmaster/public_html
ErrorLog /var/log/virtualmin/fleshmaster.org_error_log
CustomLog /var/log/virtualmin/fleshmaster.org_access_log combined
ScriptAlias /cgi-bin/ /home/fleshmaster/cgi-bin/
ScriptAlias /awstats/ /home/fleshmaster/cgi-bin/
DirectoryIndex index.php index.html index.htm index.php4 index.php5
<Directory /home/fleshmaster/public_html>
Options -Indexes +IncludesNOEXEC +SymLinksifOwnerMatch +ExecCGI
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
AddHandler fcgid-script .php
AddHandler fcgid-script .php5
FCGIWrapper /home/fleshmaster/fcgi-bin/php5.fcgi .php
FCGIWrapper /home/fleshmaster/fcgi-bin/php5.fcgi .php5

<Directory /home/fleshmaster/cgi-bin>
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch

RewriteEngine on
RewriteCond %{HTTP_HOST} =webmail.fleshmaster.org
RewriteRule ^(.) https://fleshmaster.org:20000/ [R]
RewriteCond %{HTTP_HOST} =admin.fleshmaster.org
RewriteRule ^(.
) https://fleshmaster.org:10000/ [R]
RemoveHandler .php
RemoveHandler .php5
IPCCommTimeout 31

AuthName “fleshmaster.org statistics”
AuthType Basic
AuthUserFile /home/fleshmaster/.awstats-htpasswd
require valid-user

RedirectMatch /cgi-bin/mailman/([^/.])(.cgi)?(.) https://fleshmaster.org:10000/virtualmin-mailman/unauthenticated/$1.cgi$3
RedirectMatch /mailman/([^/.])(.cgi)?(.) https://fleshmaster.org:10000/virtualmin-mailman/unauthenticated/$1.cgi$3
Alias /pipermail /var/lib/mailman/archives/public
php_value memory_limit 96M
php_value register_globals Off
php_admin_value engine Off
FcgidMaxRequestLen 1073741824

family.fleshmaster.org

SuexecUserGroup "#533" "#509" ServerName family.fleshmaster.org ServerAlias www.family.fleshmaster.org media.family.fleshmaster.org ServerAlias webmail.family.fleshmaster.org ServerAlias admin.family.fleshmaster.org DocumentRoot /home/fleshmaster/domains/family.fleshmaster.org/public_html ErrorLog /var/log/virtualmin/family.fleshmaster.org_error_log CustomLog /var/log/virtualmin/family.fleshmaster.org_access_log combined ScriptAlias /cgi-bin/ /home/fleshmaster/domains/family.fleshmaster.org/cgi-bin/ ScriptAlias /awstats/ /home/fleshmaster/domains/family.fleshmaster.org/cgi-bin/ DirectoryIndex index.php index.html index.htm index.php4 index.php5 Options -Indexes +IncludesNOEXEC +SymLinksifOwnerMatch +ExecCGI allow from all AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch AddHandler fcgid-script .php AddHandler fcgid-script .php5 FCGIWrapper /home/fleshmaster/domains/family.fleshmaster.org/fcgi-bin/php5.fcgi .php FCGIWrapper /home/fleshmaster/domains/family.fleshmaster.org/fcgi-bin/php5.fcgi .php5 allow from all AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch RewriteEngine on RewriteCond %{HTTP_HOST} =webmail.family.fleshmaster.org RewriteRule ^(.*) https://family.fleshmaster.org:20000/ [R] RewriteCond %{HTTP_HOST} =admin.family.fleshmaster.org RewriteRule ^(.*) https://family.fleshmaster.org:10000/ [R] RemoveHandler .php RemoveHandler .php5 php_admin_value engine Off IPCCommTimeout 61 AuthName "family.fleshmaster.org statistics" AuthType Basic AuthUserFile /home/fleshmaster/domains/family.fleshmaster.org/.awstats-htpasswd require valid-user RedirectMatch /cgi-bin/mailman/([^/\.]*)(.cgi)?(.*) https://family.fleshmaster.org:10000/virtualmin-mailman/unauthenticated/$1.cgi$3 RedirectMatch /mailman/([^/\.]*)(.cgi)?(.*) https://family.fleshmaster.org:10000/virtualmin-mailman/unauthenticated/$1.cgi$3 Alias /pipermail /var/lib/mailman/archives/public FcgidMaxRequestLen 1073741824 php_value memory_limit 96M

from php.ini for both:
date.timezone = America/Los_Angeles

Update: This issue fixed itself, no idea how or why, multiple reboots do not normally fix issues, but I have not ruled out cached results.