[BlueOnyx:08402] Re: Vacation Message Times
mstauber at blueonyx.it
Wed Sep 7 11:58:30 PET 2011
> 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
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.
Things get even a bit more complicated with PHP-5.3, which we use on 5107R for
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"];
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
Sadly this class hard-wired the timezone settings back to UTC and therefore
ignored the system timezone:
// get selected values
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
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.
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
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
With best regards
More information about the Blueonyx