[kronolith] (no subject)
Jan Schneider
jan at horde.org
Wed Jul 28 12:59:26 PDT 2004
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
More information about the kronolith
mailing list