[kronolith] (no subject)

[Jan Schneider]

Zitat von Samuel Nicolary <sam at nicolary.org>:

> On Wed, 28 Jul 2004, Jan Schneider wrote:
>
>> Zitat von Samuel Nicolary <sam at nicolary.org>:
>>
>> > One last thing - it seems that it is quite often the case that the
>> > environment that the web server is running under does not have a timezone
>> > environment setting and therefore the default timezone becomes UTC in a
>> > lot of cases.  This issue could be mitigated by adding a Horde
>> > configuration variable to set the server default if it isn't set by the
>> > server environment.
>>
>> I lost you here.
>
> For instance: on a vanilla Redhat Fedora install the environment under
> which root starts the apache process does not have the TZ variable set so
> unless the systems hardware clock is set to UTC and the /etc/localtime
> links to the /usr/share/zoneinfo/UTC then the local time functions in PHP
> are not going to behave as expected because they won't necessarily be
> setting the correct offsets since the will assume you are in a UTC
> timezone which you may not be.  Say the system time is actually set to
> EST5EDT and the local time functions think you are in UTC and they go to
> work on a PST8PDT date - the offset will be calculated as -0700 or -0800
> from UTC depending on DS instead of -0300 from EST5EDT.

Got it.

> If the system administrator sets the TZ variable in the environment to the
> correct timezone or sets it in the apache config with a "SetEnv TZ
> <timezone>" then everything will be alright but the sure way of doing it
> is to require the Horde administrator to set the site default timezone in
> the /horde/config/conf.php file and having this value set early in the
> environment of the executing PHP process before any date values get
> evaluated.

Yeah, makes sense to me.

Jan.

--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting.php