[kronolith] (no subject)

[Jan Schneider]

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

> I am working on a patch to Kronolith that supports timezone factoring in
> the display of the calendars and also storage of the date fields in UTC in
> the kronolith_events table.  I have it working - in order to do so I
> implemented it as follows:
>
> Disabled the NLS::setTimeZone call in kronolith/lib/base.php.
> Disabled the NLS::setTimeZone call in nag/lib/base.php.
>
> Created two methods in the Kronolith_Event class: toUTC and fromUTC.
>
> These methods utilize the Date PEAR module and the user's timezone
> preference to convert the date items to and from UTC
>
> Modified the constructor method of the Kronolith_Event class in
> Driver.php:
>
>     function Kronolith_Event(&$driver, $eventObject = null)
>     {
>         $this->_calendar = $driver->getCalendar();
>
>         if (isset($eventObject)) {
>             $this->fromDriver($eventObject);
>             // to offset the date fields from UTC to the user's preference
>             $this->fromUTC();
>         }
>     }
>
> Modified the save method of the Kronolith_Event class in Driver.php:
>
>     function save()
>     {
>         if (!$this->isInitialized()) {
>             return PEAR::raiseError('no data');
>         }
>         // to standardize the date fields to UTC from the user's preference
>         $this->toUTC();
>         $this->toDriver();
>         $driver = &$this->getDriver();
>         return $driver->saveEvent($this);
>     }

Looks good.

> One of the implications of this is that for any other modules (e.g. Nag)
> to integrate with Kronolith now they also have to store dates in UTC and
> the fromUTC and toUTC functions should be implemented in their modules to
> comply to this spec where it is appropriate to do so.

If this is the case these methodd should be implemented in NLS:: instead to
have them in a single place.

> I am not comfortable with using putenv to taint the server process'
> environment to accomplish date offsetting.  It works with
> the limited use with which it is employed now but it takes away the
> control that may be needed in the future to compare data from multiple
> users from different timezones.

Agreed.

> Given the lack of a native full set of date and time functions in the PHP
> interpreter and the presence of these features in the PEAR Date module it
> seems to me that any date offsetting should be handled by Date objects.
> To take this a step further it seems appropriate to represent all date
> fields handled within the Horde framework and its modules as Date objects.
> I see framework support for this in form retrieval but it doesn't look
> like this is being taken advantage of within Kronolith.

This is something I always planned to do, at least for Kronolith. Full ack.

> At the very least it seems that the Kronolith_Event startTimestamp,
> endTimestamp and recurEndTimestamp attributes should be folded into the
> start, end and recurEnd attributes and the start, end and recurEnd
> attributes should become Date objects.  This would simplify a lot of the
> method calls within the class as they would become aliases to Date object
> methods.  It seems to me at first glance that this would also simplify the
> storage driver extensions.

Makes sense if we want to use Date objects instead of timestamps.

> I am still getting my bearings within the code so excuse me if I have made
> any mistakes in my understanding of the current implementation.
>
> 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.

Jan.

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