Timezone handling in EGroupware

classic Classic list List threaded Threaded
8 messages Options
Ralf Becker Ralf Becker
Reply | Threaded
Open this post in threaded view
|

Timezone handling in EGroupware

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: [hidden email]

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
Nathan Gray-2 Nathan Gray-2
Reply | Threaded
Open this post in threaded view
|

Re: Timezone handling in EGroupware


On 6-Oct-09, at 10:15 AM, Ralf Becker wrote:

> ...
> 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.

What about modifying $GLOBALS['egw']->db->from_timestamp() to return  
either a timestamp corrected to the user's timezone (default) or a  
timestamp in the server time?  I believe that's the function I use for  
converting from DB specific timestamps.


Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
Ralf Becker Ralf Becker
Reply | Threaded
Open this post in threaded view
|

Re: Timezone handling in EGroupware

Hi Nathan,

Nathan Gray schrieb:

> On 6-Oct-09, at 10:15 AM, Ralf Becker wrote:
>
>> ...
>> 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.
>
> What about modifying $GLOBALS['egw']->db->from_timestamp() to return  
> either a timestamp corrected to the user's timezone (default) or a  
> timestamp in the server time?  I believe that's the function I use for  
> converting from DB specific timestamps.

Problem in that case would be, that the application code would also try
to add it's offset. Which in sum leads again to a wrong result.

But that's not really a problem, I need to find a place where I can do
the change with as little modification of the current code as possible,
but not less ;-)

Btw. do you already use the automatic timestamp conversation of so_sql
in your code?
This is done by either setting $so->timestamps = array('time1','time2')
or if you use database timestamps, by calling $so->convert_all_timestamps().
I recommend that over doing it in the extended class db2data and data2db
methods "by hand" (as it's the case in most apps using so_sql
currently). If so_sql "knows" what columns contain timestamps, it can
handle them automatic, even with the new code.

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: [hidden email]

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
Nathan Gray-2 Nathan Gray-2
Reply | Threaded
Open this post in threaded view
|

Re: Timezone handling in EGroupware


On 6-Oct-09, at 12:23 PM, Ralf Becker wrote:

> ...
> Btw. do you already use the automatic timestamp conversation of so_sql
> in your code?

Unfortunately since most pERP apps are so complicated, and usually  
deal with several things, I can't make much use of so_sql or its  
children.  Whenever I start trying, I usually encounter some  
complicated query that needs to be custom handled, and I have to go to  
an independent SO anyway.

Currently I don't even do any user / server time conversions at all...

Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
Ralf Becker Ralf Becker
Reply | Threaded
Open this post in threaded view
|

Re: Timezone handling in EGroupware

In reply to this post by Ralf Becker
A first step is implemented and commited:
http://www.egroupware.org/viewvc/egroupware?rev=28049&view=rev

New egw_time class used to implement correct timezone handling for
calendar, plus a first calendar implemenation.

This implementation just replaces following calendar_bo methods:
- date2ts($date,$user2server=False)
- date2array($date,$server2user=False)
- date2string($date,$server2user=False,$format='Ymd')
- format_date($date,$format='')
which static methods from egw_time.

If your server is in same timezone as the user, you should experience no
difference. As a small test, you can switch to an other timezone (eg.
UTC) to recognice on a weekly repeating event (which still repeats on
equal server time!) that it moves by one hour when daylight saving
changes. This switching to a TZ with different daylight saving rules,
was not working before.

Happy testing  :-)

Ralf

Ralf Becker schrieb:

> 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
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
eGroupWare-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
Joerg Lehrke-2 Joerg Lehrke-2
Reply | Threaded
Open this post in threaded view
|

Re: Timezone handling in EGroupware

In reply to this post by Ralf Becker
Hi Ralf,

we opened Pandoras box with the recurring event handling within SyncML ;-)
This is where I forsee the most problems with the timezone calculations.
A user may create a recurring event which can be handled as a single entry
within his timezone. But with the timezone differences you may need to split
the series in separate parts in server time (think of UTC as server time).
I guest the comunity will appreciate a working timezone support but to get it
right sounds like a lot of work to me.
Go ahaead and good luck!

        Cheers,
         J"org
On Tuesday 06 October 2009, Ralf Becker wrote:

> 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
--
Joerg Lehrke     http://k.noc.de/    GnuPG-KeyID: C66844AC
Bgm.-Haffner-Str. 7,      D-87600 Kaufbeuren,      Germany
Tel +49 176 63127967          GNU -- Protect your freedom!

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
eGroupWare-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
Hans-Jürgen Tappe Hans-Jürgen Tappe
Reply | Threaded
Open this post in threaded view
|

Re: Timezone handling in EGroupware

Hi!

Joerg Lehrke schrieb:
> we opened Pandoras box with the recurring event handling within SyncML ;-)
> This is where I forsee the most problems with the timezone calculations.
> A user may create a recurring event which can be handled as a single entry
> within his timezone. But with the timezone differences you may need to split
> the series in separate parts in server time (think of UTC as server time).
> I guest the comunity will appreciate a working timezone support but to get it
> right sounds like a lot of work to me.

Just a thought from my side: The event should store the base time in UTC
and then display event in the user's timezone and send mails in the
server's timezone (I think, that's how it is handles currently if the
server uses UTC).

Regards,
Hans-Jürgen


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
eGroupWare-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
Ralf Becker Ralf Becker
Reply | Threaded
Open this post in threaded view
|

Re: Timezone handling in EGroupware

Hi Hans-Jürgen,

Hans-Juergen Tappe schrieb:

> Hi!
>
> Joerg Lehrke schrieb:
>> we opened Pandoras box with the recurring event handling within SyncML ;-)
>> This is where I forsee the most problems with the timezone calculations.
>> A user may create a recurring event which can be handled as a single entry
>> within his timezone. But with the timezone differences you may need to split
>> the series in separate parts in server time (think of UTC as server time).
>> I guest the comunity will appreciate a working timezone support but to get it
>> right sounds like a lot of work to me.
>
> Just a thought from my side: The event should store the base time in UTC
> and then display event in the user's timezone and send mails in the
> server's timezone (I think, that's how it is handles currently if the
> server uses UTC).

That's not correctly describing the current situation. Currently the
server uses some timezone (which can be UTC). If it is UTC, some stuff
in EGroupware is NOT working correct. Full functionality (recurring
events over daylight saving changes) only works, if the server is in the
same timezone as the user (or at least switches as same times). So
that's probably the majority of the installations we have.

To not run into desperate update scenarios, I will not tough that.
Meaning if an EGroupware instance currently stores in timezone
'Europe/Berlin', we will keep that.

For calendar and all new applications, we run the SO layer on server
time(zone) and convert in BO all access to and from SO. So above BO
everything is handled in user time(zone).

As all above described the current situation (EGw 1.6, Trunk 'til
yesterday), I plan not to change the concepts. Only thing which is going
to change in a first step, is the way the conversation is done between
SO and BO.

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: [hidden email]

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(R) 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/devconference
_______________________________________________
eGroupWare-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/egroupware-developers