[BlueOnyx:08402] Re: Vacation Message Times

[Michael Stauber]

Hi Rickard,

>  It is all based on unixtime which shouldn't
>  give any problems. Could you please check and post what hwclock and date
> tells you as well?

The problem there was multi-layered, Rickard and it also created a bit of 
headache. 

The code for vacation message times uses the PHP function time() to create 
timestamps for when the messages should start and stop. 

The problem there is that time() ignores the timezone settings and will always 
assume UTC as timezone.

See: http://de3.php.net/manual/en/function.time.php

Things get even a bit more complicated with PHP-5.3, which we use on 5107R for 
the GUI.

Since PHP-5.3 usage of time related functions throws very visible warnings is 
'date.timezone' is not set through either php.ini or through 
date_default_timezone_set() within the PHP scripts themselves.

To counter this since 5107R our ServerScriptHelper.php (which is used 
everywhere by any GUI page) reads the configured timezone from CODB and uses 
date_default_timezone_set() to set it globally for all GUI PHP scripts:

        // initialize timezone  
        $timeObj = $cceClient->getObject("System", array(), "Time");
        $systemTimeZone = $timeObj["timeZone"];
        date_default_timezone_set($systemTimeZone);

Still: Any time related GUI pages showed the time based on UTC values. That 
included pages such as:

	- The initial setup wizard pages where you set the timezone
	- The "System Settings" / "Time" page
	- The new pages that show the vacation message start/stop time

The reason for this is that all these pages use the PHP class "TimeStamp" as 
provided by libPhp/uifc/TimeStamp.php to render the pulldown menus for time 
and date.

Sadly this class hard-wired the timezone settings back to UTC and therefore 
ignored the system timezone:

    // get selected values
    date_default_timezone_set('UTC');

Which makes a bit of sense as the stamps are really based on UTC anyway. But 
in our case it'll mean that the displayed time is always as far off as the 
servers clock differs from UTC. Unless we calculate in an offset everyhwere - 
which is really, really messy. But at one place or other during this chain the 
difference between UTC and system timezone HAS to be taken into account.

To counter these problems I published two updates to SVN during the last 24 
hours:

1.) http://devel.blueonyx.it/trac/changeset/764/

This removes the fallback to UTC in libPhp/uifc/TimeStamp.php and makes sure 
that our date and time related GUI pages show the time based on the server 
time - and not UTC.

2.) http://devel.blueonyx.it/trac/changeset/762

This change goes a bit further and does the following:

Both /etc/php.ini (and / or a third party PHP's php.ini file - if present!) 
and /etc/admserv/php.ini will now have an extra line where 'date.timezone' is 
set to the servers configured timezone.

On CCE restart or server start a missing 'date.timezone' is added to both 
php.ini files. It is also made sure that it doesn't get dropped during changes 
to php.ini and furthermore it is made sure that during changes of the server 
timezone settings both php.ini's will be updated, too.

Sadly: Due to the intricracies of AdmServ I cannot allow it to be restarted by 
a constructor or handler during runtime, as that would throw off GUI based PKG 
installs.

So if the timezone settings of the server are changed, chances are that the 
changes won't be picked up until the next time that AdmServ is restarted. But 
in that case we still have the fallback in ServerScriptHelper.php which sets 
the timezone for all scripts based on the TZ stored in CODB. So this should be 
an acceptable compromise.

Before I release this updates tonight I'll have to check in how far 
/usr/local/sbin/vacation.pl is thrown off by this, as I'm still trying to 
figure out if it also just works on UTC, or if it honours the timezone 
settings.

-- 
With best regards

Michael Stauber