[BlueOnyx:08403] Re: Vacation Message Times

[Rickard Osser]

Hi Michael,

thanks, I haven't had time to check this out... Sorry... 
I'm in the ending phase of finishing our Virtual server (you know what I
mean)... I'm going to install the first "real" machine in our customers
support department tomorrow... That will give us valuable feedback as
well as the highway in to their sales department.

If it works there, they'll start sell it actively. 

Thanks again,
Rickard

On Wed, 2011-09-07 at 18:58 +0200, Michael Stauber wrote:
> 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.
>