[kronolith] (no subject)

[Samuel Nicolary]

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);
    }

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.

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.

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.

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.

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.

Thoughts?

-- 
Sam Nicolary