Current Situation:
EGroupware uses a static difference between user and server time(zone).
The difference between user and server time is stored in the user
preferences. It works ok, if your server uses the same timezone, as the
user or at least switches at same time to and from daylight saving.
If the server uses eg. UTC, things like recurring events jump one hour
when daylight saving changes. An other situation we can not handle at
all, is users from different timezone around the globe, which switch at
different time to and from daylight saving (eg. one in Germany and one
in Australia).
As we do not store a timezone, when a user creates a recurring event,
it’s also undefined if the event should recur at the same time in that
timezone or in UTC.
Planned solution:
Already committed is a fix, which allows users to select a real timezone
in their preferences (eg. “Europe/Berlin”) instead of a difference
between user and server time. That timezone is already used to calculate
the old tz_offset preference, thought only at current date.
The full solution, I’m working on right now, will use a server timezone
(which is also used by the database) and a user timezone. Now we need to
convert every single timestamp when read from or written to the
database, between this timezones. Unless user and server time switch at
the same date to and from daylight saving, this conversation depends on
the date, meaning it’s not just about adding/subtracting a static value.
To do the conversation I want to use the - in PHP 5.2 introduced -
DateTime and DateTimeZone objects, as they implement everything
necessary for a correct timezone handling. The ideal solution would be
to convert all timestamps read from database (either real database
timestamps or integer unix timestamps), to new DateTime objects.
Unfortunately that would require changing all application code, to deal
with the new objects 
I estimate that’s a multiple week job.
So my current plan is to only fix the current adding/subtracting of a
static timezone offset, which usually happens in EGroupware code between
BO and SO (business and storage objects). That will be done by two
static methods of a new egw_time class:
/**
- Convert a server time into a user time
-
-
@param int|string|array|datetime $time
-
@param string $type=null type or return-value, default (null) same as
$time
-
@return int|string|array|datetime
*/
public static function server2user($time,$type=null)
/**
- Convert a user time into a server time
-
-
@param int|string|array|datetime $time
-
@param string $type=null type or return-value, default (null) same as
$time
-
@return int|string|array|datetime
*/
public static function user2server($time,$type=null)
When ever possible I will prepare for the full solution, eg. so_sql
class will allow to choose if one wants to use DateTime object or the
current integer timestamps or ‘Y-m-d H:i:s’ strings used by the database.
Timeline:
I have about one week to get the new timezone handling implemented.
Needless to say:
- please comment on the plan
- prepare of a not (fully) usable trunk for the next 1-2 weeks, be
warned 
Ralf
Ralf Becker
Director Software Development
Stylite GmbH
[open style of IT]
Morschheimer Strasse 15
67292 Kirchheimbolanden
fon +49 (0) 6352 70629-0
fax +49 (0) 6352 70629-30
mailto: rb@stylite.de
www.stylite.de
www.egroupware.org
Geschäftsführer Andre Keller,
Gudrun Müller, Ralf Becker
Registergericht Kaiserslautern HRB 30575
Umsatzsteuer-Id / VAT-Id: DE214280951
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
