[BlueOnyx:25009] Re: Vacation message timezone

[Michael Stauber]

Hi Andreas,

> when setting up a vacation message, the start and end time seems to be using "America/New_York" as timezone.
> Which in our case means that the start and end time is about 6 hours off.
> 
> If I change
> 
> if (!isset($timeObj["timeZone"])) {
>     $timeObj["timeZone"] = "America/New_York";
> }
> 
> to something else, like
> 
> if (!isset($timeObj["timeZone"])) {
>     $timeObj["timeZone"] = "Europe/Berlin";
> }
> 
> in /usr/sausalito/ui/chorizo/ci/application/libraries/ServerScriptHelper.php, it's using the correct timezone.
> 
> Which setting sets $timeObj["timeZone"]? It doesn't seem to be the systems timezone in "System Settings" -> "Time".
> Is there another timezone setting?

Ok, let's start with some basics and I'll walk you through how this works:

We have two ways looking at this problem. Top down and beginning at the
GUI page where you set the date and time for the vacation messages.

That would be https://<GUI>:81/user/personalEmail

Or we could start bottom up at the script that sends the actual vacation
message: /usr/local/sbin/vacation.pl

That is called via a .forward file in the users home directory and then
has something like this in it:

[root at 5210r admin]# cat .forward
# VACATIONSTART
\admin, "|/usr/local/sbin/vacation.pl /home/.users/admin/.vacation_msg
admin"
# VACATIONEND

Let us start top down: T

When you look at the sources of the GUI page /user/personalEmail you
might wonder where the heck the actual form fields are where you set the
date and times:

https://devel.blueonyx.it/trac/browser/BlueOnyx/5210R/ui/base-user.mod/ui/chorizo/web/controllers/PersonalEmail.php#L104

They're out-sourced into an so called "AutoFeature" file. These are
re-usable modules that can be loaded and aggregated into a single (or
multiple different) GUI pages as needed. We use them whenever a GUI page
needs to be extendible. The AV-SPAM for example has email management
elements that should go into /user/personalEmail as well. So we made all
 these elements individual "AutoFeature" elements and
/user/personalEmail aggregates them into a single page that has all the
form fields and their handling mechanisms.

You see, /user/personalEmail loads the "AutoFeatures" of type
'User.Email'. Which we find here on the server:

[root at 5210r ~]# ls -k1 /usr/sausalito/ui/chorizo/extensions/User.Email/
10_EmailSettings.php
20_ImapSync.php
30_SPAM.php

The one that has (among other things) the vacation message stuff is this
one: 10_EmailSettings.php

You can see the code for it here:

https://devel.blueonyx.it/trac/browser/BlueOnyx/5210R/ui/base-user.mod/ui/chorizo/extensions/10_EmailSettings.php.User.Email

This AutoFeature module saves the start- and end-date for vacation
messages as UNIX time stamps into the GUI backend CODB:

Down in line 508 (See:
https://devel.blueonyx.it/trac/browser/BlueOnyx/5210R/ui/base-user.mod/ui/chorizo/extensions/10_EmailSettings.php.User.Email#L508
) it does a CCE SET transaction:

	$cceClient->set($prams['CCE_OID'], "Email", $CODBout);

The CCE_OID is the CODB database object of the user in question, we
write to the NameSpace "Email" of that object and tell it to write the
contents of $CODBout to it. That array might look like this:

Array
(
    [forwardEnable] => 0
    [forwardEmail] =>
    [forwardSave] => 0
    [vacationOn] => 1
    [vacationMsg] => I'm out of office. Blah ...
    [vacationMsgStart] => 1625152500
    [vacationMsgStop] => 1627744500
    [do_not_reply] => &test at solarspeed.net&
    [do_not_reply_from] => &admin at 5210r.smd.net&
)

As you can seem the keys 'vacationMsgStart' and 'vacationMsgStop' have
the date and time as Unix time stamps.

Now let us take a look at the actual script that sends the vacation
messages (/usr/local/sbin/vacation.pl). It polls the CCEd CODB object of
the User in question and checks what settings the NameSpace 'Email' for
that User has configured:

https://devel.blueonyx.it/trac/browser/BlueOnyx/5210R/ui/base-email.mod/glue/usr/local/sbin/vacation.pl#L149

The decision if we send or don't send email based on start- and end-date
is made around here:

https://devel.blueonyx.it/trac/browser/BlueOnyx/5210R/ui/base-email.mod/glue/usr/local/sbin/vacation.pl#L286

	if (!($startDate < time() && $stopDate > time())) {
		# We will not use vacation!
		...
	}

So we compare if $startDate (from CODB) is smaller than the value stored
in time() (which is the systems Unix time stamp) or if $stopDate (also
from CODB) is larger than time().

So in essence this tells us that the decision about when and if to send
vacation messages is based on the Unix time stamp:

The GUI stores the desired Unix time stamp for start/stop date into CODB
and the vacation message script (when called) compares these stored
values with the actual and current Unix time stamp.

The conclusion here is that *if* your start/stop date are off by one or
more time zones, then we should take a look at which time zone either
the GUI or the vacation message script use when they do their calculations.

On your BlueOnyx go to https://<GUI>:81/time/timeconfig and see what
time zone you have configured. I presume it's "Europe/Berlin".

Make sure to check if that coincides with what is actually configured on
the OS level:

[root at 5210r ~]# ls -la /etc/localtime
lrwxrwxrwx 1 root root 34 25. Sep 2019  /etc/localtime ->
../usr/share/zoneinfo/Europe/Berlin

When changing the time zone the GUI will point the Symbolic Link
/etc/localtime to the time zone you want to have configured. But make
sure yours is really the same as the GUI says it is.

Additionally: Make sure that /etc/admserv/php.ini (the php.ini that is
used for the GUI's AdmServ) also has the desired time zone set:

[root at 5210r ~]# cat /etc/admserv/php.ini |grep date.timezone
date.timezone = 'Europe/Berlin'

Because if *this* is set to a different time zone, then the Unix time
stamps of desired start/end dates for vacation messages *will* be off by
as much as the time zone differs from your local time.

Lastly: /usr/local/sbin/vacation.pl will always run with the time zone
in mind that's configured via /etc/localtime

I suspect you either have /etc/localtime or /etc/admserv/php.ini
pointing to 'America/New_York' and that's causing the issue.

As for your question about
/usr/sausalito/ui/chorizo/ci/application/libraries/ServerScriptHelper.php
and ...

> if (!isset($timeObj["timeZone"])) {
>     $timeObj["timeZone"] = "America/New_York";
> }

... that one? No, this is a general routine that makes sure that
whatever is set via the GUI when writing the server time zone has at
least *something* in it. Usually $timeObj["timeZone"] *would* contain
the time zone you configured via the GUI under
https://<GUI>:81/time/timeconfig or via https://<GUI>:81/wizard/wizard

But if $timeObj["timeZone"] is empty for whatever reason when 'System' .
'Time' is updated in CODB, then it would instead set 'America/New_York'.
Just to make sure that *something* is present.

This isn't used at all during vacation message processing and only comes
into play during initial server configuration on the web based wizard,
or via "Server Management" / "System Settings" / "Time" when you change
the time, date or time zone.

-- 
With best regards

Michael Stauber