From bernhard at intevation.de  Mon Jun  2 13:03:54 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 2 Jun 2008 13:03:54 +0200
Subject: Timezone issues
In-Reply-To: <200805260954.05097.martin.konold@erfrakon.de>
References: <200805260954.05097.martin.konold@erfrakon.de>
Message-ID: <200806021303.58433.bernhard@intevation.de>

Hi Martin,

On Monday 26 May 2008 09:54, Martin Konold wrote:
> When entering a date e.g. for an event KDE Kontact should use
>
> <time-zone>(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm,
> Wien</time-zone>

what do you mean by "entering" a date?
(I've just tried Kontact 1.2.9 (enterprise 20080520.810305)
and created an event and looked at the resultung Kolab-xml file,
there is no <time-zone> tag in there.)


> NOT
>
> <time-zone>(GMT+02:00) Amsterdam, Berlin, Bern, Rom, Stockholm,
> Wien</time-zone>
>
> even though we currently have DST in Germany.
>
>
> Rational: The timezone is solely dependend on the geographic location but
> not on the week. This is especially important for events spanning over DST
> switching sundays.

Well, both variants do not seem to be a nice specification of a time-zone,
they both are wrong about half of the year. 
Currently we do not have "time-zone" in the specification.
Are you proposing to add it?
(I would welcome this as I believe that there is a rare problem
when specifying recurrent events, which we discussed years ago.)

> E.g. a daily recurring event at 12 noon like "lunch" shall always happen at
> the same time and not be affected by daylight saving time switches.

Correct means it should happen on the same time within the time zone,
so in summer time it is always 12:00 (even when this is 11:00 or 10:00 UTC 
depending on the daylight saving period it occurs in).


> BTW: This is something which MS Outlook 2K3 does correct ;-)

I believe Kontact does this correctly, though.
If not please let us know the test case or directly file an issue
in the tracker.

Thanks,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20080602/4dee7af2/attachment.bin

From bernhard at intevation.de  Mon Jun  2 13:58:20 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 2 Jun 2008 13:58:20 +0200
Subject: [Kolab-devel] distributionlists testing
In-Reply-To: <200805260921.50606.martin.konold@erfrakon.de>
References: <20080418132326.953537gt046m8aem@mail.das-netzwerkteam.de>
	<200805221126.38253.bernhard@intevation.de>
	<200805260921.50606.martin.konold@erfrakon.de>
Message-ID: <200806021358.24612.bernhard@intevation.de>

Hi Martin,

On Monday 26 May 2008 09:21, Martin Konold wrote:
> > > The mimetype of this attachment will be
> > > "application/x-vnd.kolab.<type>" where type is the content type of the
> > > file.
> > > (http://kolab.org/doc/kolabformat-2.0rc7-html/x179.html)
> > >
> > > Looking at the Kontact source code on the other hand reveals that
> > > Kontact uses the same mime type :(
> >
> > If this is the case, we might also consider changing the kolab-format
> > spec as we will have quite a few objects of this type out there in the
> > wild.
>
> I strongly object to this way of dealing with implementation problems. If
> the standard is not broken but the implementations are broken then fix the
> implementations but not the standard.
>
>
> The former approach is the reason for too many problem in other areas like
> html where implementations finally defined the standards...
>
> So fix the implementations and use the version numbering schema for
> backwards compatibility.

this might be true in the general case, but we are looking at a specific case.
Do you know any implementation that is _not_ following the Kontact or Toltec
implementation? If there is non, and there is no other drawback, we would only 
put the burden on implementors and users - without any practical gain
for the first release that is called "stable".

So I believe this should be considered in concrete terms.

Bernhard
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20080602/6cad2767/attachment.bin

From wrobel at pardus.de  Tue Jun  3 14:05:51 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 03 Jun 2008 14:05:51 +0200
Subject: [Kolab-devel] distributionlists testing
In-Reply-To: <200806021358.24612.bernhard@intevation.de> (Bernhard Reiter's
	message of "Mon, 2 Jun 2008 13:58:20 +0200")
References: <20080418132326.953537gt046m8aem@mail.das-netzwerkteam.de>
	<200805221126.38253.bernhard@intevation.de>
	<200805260921.50606.martin.konold@erfrakon.de>
	<200806021358.24612.bernhard@intevation.de>
Message-ID: <87r6ben2ow.fsf@home.pardus.de>

Bernhard Reiter <bernhard at intevation.de> writes:

> Hi Martin,
>
> On Monday 26 May 2008 09:21, Martin Konold wrote:
>> > > The mimetype of this attachment will be
>> > > "application/x-vnd.kolab.<type>" where type is the content type of the
>> > > file.
>> > > (http://kolab.org/doc/kolabformat-2.0rc7-html/x179.html)
>> > >
>> > > Looking at the Kontact source code on the other hand reveals that
>> > > Kontact uses the same mime type :(
>> >
>> > If this is the case, we might also consider changing the kolab-format
>> > spec as we will have quite a few objects of this type out there in the
>> > wild.
>>
>> I strongly object to this way of dealing with implementation problems. If
>> the standard is not broken but the implementations are broken then fix the
>> implementations but not the standard.
>>
>>
>> The former approach is the reason for too many problem in other areas like
>> html where implementations finally defined the standards...
>>
>> So fix the implementations and use the version numbering schema for
>> backwards compatibility.
>
> this might be true in the general case, but we are looking at a specific case.
> Do you know any implementation that is _not_ following the Kontact or Toltec
> implementation? 

Horde obviously but that is of course rather new and can be modified.

> If there is non, and there is no other drawback, we would only 
> put the burden on implementors and users - without any practical gain
> for the first release that is called "stable".

Concerning the implementation this exception requires a pretty useless
bit of code and I believe it makes sense to stick to the original
intention of the format description.

I'm not saying that we should declare the current implementations as
invalid. But we should just mark it as an exception, suggest newer
clients to allow reading both formats while writing the correct
format. This way we could at least try to phase out this type of
exception as I don't see a really convincing reason to keep it around.

Cheers,

Gunnar

>
> So I believe this should be considered in concrete terms.
>
> Bernhard
> -- 
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From konold at erfrakon.de  Tue Jun  3 00:28:07 2008
From: konold at erfrakon.de (Martin Konold)
Date: Tue, 3 Jun 2008 00:28:07 +0200 (CEST)
Subject: Timezone issues
In-Reply-To: <200806021303.58433.bernhard@intevation.de>
References: <200805260954.05097.martin.konold@erfrakon.de>
	<200806021303.58433.bernhard@intevation.de>
Message-ID: <Pine.LNX.4.64.0806022337560.6564@mail.hq.erfrakon.de>


Hi Bernhard,

>> When entering a date e.g. for an event KDE Kontact should use
>>
>> <time-zone>(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm,
>> Wien</time-zone>
>
> what do you mean by "entering" a date?

I mean creating an event with the KDE Kontact (KOrganizer) UI.

> (I've just tried Kontact 1.2.9 (enterprise 20080520.810305)
> and created an event and looked at the resultung Kolab-xml file,
> there is no <time-zone> tag in there.)

This is the report from a user on Debian stable:

User-Agent: KONSEC Konnektor 1.1.8.1
X-KONN-ENTRYID: 000000002E364946FA823D4CB5A733B3C3E57C5EA4932000
X-KONN-IMPORTANCE: 1
X-KONN-SENSITIVITY: 0
X-Kolab-Type: application/x-vnd.kolab.event
X-MS-TNEF-Correlator: 000000002E364946FA823D4CB5A733B3C3E57C5EA4932000
Mime-Version: 1.0
From: Some Testuser <test.user at xxxx.bund.de>[D
Subject: 93F8AC566C3DE8419DC85BF1B9825F60
Date: Tue, 13 May 2008 16:19:12 +0200   <--------------here correct !
X-KONN_CLIENT_SUBMIT: Tue, 13 May 2008 16:19:12 +0200
Message-ID: <4829A360.000001.00798 at unknown.host>
Content-Type: Multipart/Mixed;
   boundary="------------Boundary-00=_049TrDhZwyzf3w8CRv6t"

--------------Boundary-00=_049TrDhZwyzf3w8CRv6t
Content-Type: Text/Plain; charset=
Content-Transfer-Encoding: base64


--------------Boundary-00=_049TrDhZwyzf3w8CRv6t
Content-Transfer-Encoding: quoted-printable
Content-Type: application/x-vnd.kolab.event; name=event.xml
Content-Disposition: attachment; filename=event.xml

<?xml version=3D=221.0=22 encoding=3D=22UTF-8=22?>
<event version=3D=221.0=22>
   <product-id>KONSEC Konnektor 1.1.8.1 Build: Mar 17 2008</product-id>
   <netmeeting-type>0</netmeeting-type>
   <is-all-day-event>0</is-all-day-event>
   <show-time-as>busy</show-time-as>
   <meeting-status>0</meeting-status>
   <duration>30</duration>
   <response-status>0</response-status>
   <recurrence-type>0</recurrence-type>
   <time-zone>(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, 
Wien</time-zone> <-------- this does correctly not reflect DST
   <is-recurring>0</is-recurring>
   <conference-server-allow-external>1</conference-server-allow-external>
   <cal-unknown-0x8124>0</cal-unknown-0x8124>
   <cal-unknown-0x8224>-1</cal-unknown-0x8224>
   <cal-unknown-0x8256>0</cal-unknown-0x8256>
   <cal-unknown-0x8207>0</cal-unknown-0x8207>
   <cal-unknown-0x8257>0</cal-unknown-0x8257>
   <cal-unknown-0x8259>0</cal-unknown-0x8259>
   <cal-unknown-0x825a>0</cal-unknown-0x825a>
   <cal-unknown-0x8235>2008-05-13T16:00:00Z</cal-unknown-0x8235>
   <cal-unknown-0x8236>2008-05-13T16:30:00Z</cal-unknown-0x8236>
   <cal-unknown-0x8245>0</cal-unknown-0x8245>
   <cal-unknown-0x8201>0</cal-unknown-0x8201>
   <unknown-0x8510>369</unknown-0x8510>
   <unknown-0x8518>0</unknown-0x8518>
   <priority>0</priority>
   <sensitivity>public</sensitivity>
   <private>0</private>
   <summary>Test-Zeitverschiebung bei Terminen-aap</summary>
   <creation-date>2008-05-13T14:18:50Z</creation-date>
   <last-modification-date>2008-05-13T14:18:50Z</last-modification-date>

This means that in this case the <time-zone> tag was added by the KONSEC 
Konnektor. According to the Debian user this event is off-by-one hour in 
KDE Kontact.

>> Rational: The timezone is solely dependend on the geographic location but
>> not on the week. This is especially important for events spanning over DST
>> switching sundays.
>
> Well, both variants do not seem to be a nice specification of a time-zone,
> they both are wrong about half of the year.

I tend to disagree with this statement. IMHO the location Berlin is always 
GMT+1 independent of DST. In general DST does NOT affect the timezone. The 
later is only affected by the location.

> Currently we do not have "time-zone" in the specification.
> Are you proposing to add it?

Yes. I propose to add <time-zone> to the specification and explicitly 
stating the the adaption according to the DST has always to be handled in 
the client while displaying not while storing.

> (I would welcome this as I believe that there is a rare problem
> when specifying recurrent events, which we discussed years ago.)

Why is a recurring event like weekly on Mondays at 2pm a rare use case?

>> E.g. a daily recurring event at 12 noon like "lunch" shall always happen at
>> the same time and not be affected by daylight saving time switches.
>
> Correct means it should happen on the same time within the time zone,
> so in summer time it is always 12:00 (even when this is 11:00 or 10:00 UTC
> depending on the daylight saving period it occurs in).

Yes, and therefore the time stored permanently must be independent on DST 
but dependent on explicit timezone.

This is the only safe way to store an event like 12 noon at some 
future date because DST rules are due to political reasons unpredictable (only 
guessable).

>> BTW: This is something which MS Outlook 2K3 does correct ;-)
>
> I believe Kontact does this correctly, though.
> If not please let us know the test case or directly file an issue
> in the tracker.

The above mentioned customer claims that KDE Kontact in Debian stable 
shifts the event by one hour in case the event got created with KONSEC Konnektor.

Regards,
-- martin


From martin.konold at erfrakon.de  Tue Jun  3 15:50:00 2008
From: martin.konold at erfrakon.de (Martin Konold)
Date: Tue, 03 Jun 2008 15:50:00 +0200
Subject: [Kolab-devel] distributionlists testing
In-Reply-To: <87r6ben2ow.fsf@home.pardus.de>
References: <20080418132326.953537gt046m8aem@mail.das-netzwerkteam.de>	<200805221126.38253.bernhard@intevation.de>	<200805260921.50606.martin.konold@erfrakon.de>	<200806021358.24612.bernhard@intevation.de>
	<87r6ben2ow.fsf@home.pardus.de>
Message-ID: <48454C08.7020406@erfrakon.de>

Gunnar Wrobel wrote:

Hi,

>>>>> The mimetype of this attachment will be
>>>>> "application/x-vnd.kolab.<type>" where type is the content type of the
>>>>> file.
>>>>> (http://kolab.org/doc/kolabformat-2.0rc7-html/x179.html)
>>>>>
>>>>> Looking at the Kontact source code on the other hand reveals that
>>>>> Kontact uses the same mime type :
>>>>>           
>>>> If this is the case, we might also consider changing the kolab-format
>>>> spec as we will have quite a few objects of this type out there in the
>>>> wild.
>>>>         
>>> I strongly object to this way of dealing with implementation problems. If
>>> the standard is not broken but the implementations are broken then fix the
>>> implementations but not the standard.
>>>
>>>
>>> The former approach is the reason for too many problem in other areas like
>>> html where implementations finally defined the standards...
>>>
>>> So fix the implementations and use the version numbering schema for
>>> backwards compatibility.
>>>       
>> this might be true in the general case, but we are looking at a specific case.
>> Do you know any implementation that is _not_ following the Kontact or Toltec
>> implementation? 
>>     
>
> Horde obviously but that is of course rather new and can be modified.
>   
KONSEC Konnektor uses:

Content-Type: application/x-vnd.kolab.event; name=event.xml

;-)



Yours,
-- martin


From bernhard at intevation.de  Tue Jun  3 16:09:57 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 3 Jun 2008 16:09:57 +0200
Subject: Timezone issues
In-Reply-To: <Pine.LNX.4.64.0806022337560.6564@mail.hq.erfrakon.de>
References: <200805260954.05097.martin.konold@erfrakon.de>
	<200806021303.58433.bernhard@intevation.de>
	<Pine.LNX.4.64.0806022337560.6564@mail.hq.erfrakon.de>
Message-ID: <200806031610.02131.bernhard@intevation.de>

Hi Martin,

On Tuesday 03 June 2008 00:28, Martin Konold wrote:
> >> When entering a date e.g. for an event KDE Kontact should use
> >>
> >> <time-zone>(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm,
> >> Wien</time-zone>
> >
> > what do you mean by "entering" a date?
>
> I mean creating an event with the KDE Kontact (KOrganizer) UI.
>
> > (I've just tried Kontact 1.2.9 (enterprise 20080520.810305)
> > and created an event and looked at the resultung Kolab-xml file,
> > there is no <time-zone> tag in there.)
>
> This is the report from a user on Debian stable:

Which version of Kontact? 
E.g. current and recommended is enterprise35 for Debian Etch.

> User-Agent: KONSEC Konnektor 1.1.8.1

> Content-Transfer-Encoding: quoted-printable
> Content-Type: application/x-vnd.kolab.event; name=event.xml
> Content-Disposition: attachment; filename=event.xml
>
> <?xml version=3D=221.0=22 encoding=3D=22UTF-8=22?>
> <event version=3D=221.0=22>
>    <product-id>KONSEC Konnektor 1.1.8.1 Build: Mar 17 2008</product-id>
>    <netmeeting-type>0</netmeeting-type>
>    <is-all-day-event>0</is-all-day-event>
>    <show-time-as>busy</show-time-as>
>    <meeting-status>0</meeting-status>
>    <duration>30</duration>
>    <response-status>0</response-status>
>    <recurrence-type>0</recurrence-type>
>    <time-zone>(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm,
> Wien</time-zone> <-------- this does correctly not reflect DST
>    <is-recurring>0</is-recurring>
>    <conference-server-allow-external>1</conference-server-allow-external>
>    <cal-unknown-0x8124>0</cal-unknown-0x8124>
>    <cal-unknown-0x8224>-1</cal-unknown-0x8224>
>    <cal-unknown-0x8256>0</cal-unknown-0x8256>
>    <cal-unknown-0x8207>0</cal-unknown-0x8207>
>    <cal-unknown-0x8257>0</cal-unknown-0x8257>
>    <cal-unknown-0x8259>0</cal-unknown-0x8259>
>    <cal-unknown-0x825a>0</cal-unknown-0x825a>
>    <cal-unknown-0x8235>2008-05-13T16:00:00Z</cal-unknown-0x8235>
>    <cal-unknown-0x8236>2008-05-13T16:30:00Z</cal-unknown-0x8236>
>    <cal-unknown-0x8245>0</cal-unknown-0x8245>
>    <cal-unknown-0x8201>0</cal-unknown-0x8201>
>    <unknown-0x8510>369</unknown-0x8510>
>    <unknown-0x8518>0</unknown-0x8518>
>    <priority>0</priority>
>    <sensitivity>public</sensitivity>
>    <private>0</private>
>    <summary>Test-Zeitverschiebung bei Terminen-aap</summary>
>    <creation-date>2008-05-13T14:18:50Z</creation-date>
>    <last-modification-date>2008-05-13T14:18:50Z</last-modification-date>
>
> This means that in this case the <time-zone> tag was added by the KONSEC
> Konnektor. 

Did you miss copying the <start-date>?

> According to the Debian user this event is off-by-one hour in KDE Kontact.

It is hard to judge without the <start-date> line. :)
A common mistake in Kontact configuration is that Settings -> Events -> 
Date/Time is not set to the right timezone.

> >> Rational: The timezone is solely dependend on the geographic location
> >> but not on the week. This is especially important for events spanning
> >> over DST switching sundays.
> >
> > Well, both variants do not seem to be a nice specification of a
> > time-zone, they both are wrong about half of the year.
>
> I tend to disagree with this statement. IMHO the location Berlin is always
> GMT+1 independent of DST. In general DST does NOT affect the timezone. The
> later is only affected by the location. 

Common explanations tend to differ from your view:

http://en.wikipedia.org/wiki/Daylight_saving_time#Observance_practices
   In this example, a location observing UTC+10 during standard time is at 
UTC+11 during DST; conversely, a location at UTC?10 during standard time is 
at UTC?9 during DST.

http://de.wikipedia.org/wiki/Zeitzone#Sommerzeit
   Viele L?nder wechseln in der Fr?hlingsmitte in eine andere Zeitzone, im 
Herbst wieder zur?ck. So gilt in den meisten EU-Staaten im Winter die MEZ 
(UTC+1h), in den Sommermonaten aber die mitteleurop?ische Sommerzeit (MESZ, 
UTC+2h).

Roughly translated: Many countries switch into a different timezone mid spring 
and back in the fall. So for most EU-countries it is MEZ (UTC+1h) in the 
winter and middleeuropean sommertime in the sommer (MESZ UTC+1h). 

> > Currently we do not have "time-zone" in the specification.
> > Are you proposing to add it?
>
> Yes. I propose to add <time-zone> to the specification and explicitly
> stating the the adaption according to the DST has always to be handled in
> the client while displaying not while storing.

We would need to change the datetime definition then to include timezone
information and we would need to come up with a good definition for timezone.
As this forces a massive change on all clients, I believe we should propose 
something for beyond the 2.0 spec, which is stable as it is (and having the 
shortcomings that is has).

> > (I would welcome this as I believe that there is a rare problem
> > when specifying recurrent events, which we discussed years ago.)
>
> Why is a recurring event like weekly on Mondays at 2pm a rare use case?

Well, it is not. But people argued somehow that this was not happening
due to calculations when the appointment was made.
This reduced the problem to cases where you would do calculations on the 
server with the clients having strange different daylightsaving time borders.
Making it a rare case.

I remembered testing this stuff Toltec and Kontact back and forth 
and it used to work.

> >> E.g. a daily recurring event at 12 noon like "lunch" shall always happen
> >> at the same time and not be affected by daylight saving time switches.
> >
> > Correct means it should happen on the same time within the time zone,
> > so in summer time it is always 12:00 (even when this is 11:00 or 10:00
> > UTC depending on the daylight saving period it occurs in).
>
> Yes, and therefore the time stored permanently must be independent on DST
> but dependent on explicit timezone.

You must know if daylight saving is used, yes.
If you make "Berlin" the name of that zone including daylight saving,
the "GMT+1" should be left out as it is wrong. Berlin will have GMT+1 and 
GMT+2 depending on the DST. I think Unix's TZ= works like this.

> This is the only safe way to store an event like 12 noon at some
> future date because DST rules are due to political reasons unpredictable
> (only guessable).
>
> >> BTW: This is something which MS Outlook 2K3 does correct ;-)

I claim that the GMT+1 is clearly false for Berlin in the summer.

> > I believe Kontact does this correctly, though.
> > If not please let us know the test case or directly file an issue
> > in the tracker.
>
> The above mentioned customer claims that KDE Kontact in Debian stable
> shifts the event by one hour in case the event got created with KONSEC
> Konnektor.

This is seems a special case we might want to continue discussing on the users 
list. (To comment someone would need the Kontact version, the original 
<start-date> tag and the korganiserrc setting for timezone.)

Best,
Bernhard
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20080603/a7e4efb7/attachment.bin

From martin.konold at erfrakon.de  Tue Jun  3 16:49:33 2008
From: martin.konold at erfrakon.de (Martin Konold)
Date: Tue, 03 Jun 2008 16:49:33 +0200
Subject: Timezone issues
In-Reply-To: <200806031610.02131.bernhard@intevation.de>
References: <200805260954.05097.martin.konold@erfrakon.de>	<200806021303.58433.bernhard@intevation.de>	<Pine.LNX.4.64.0806022337560.6564@mail.hq.erfrakon.de>
	<200806031610.02131.bernhard@intevation.de>
Message-ID: <484559FD.9040900@erfrakon.de>

Bernhard Reiter wrote:

Hi Bernhard,

>> I tend to disagree with this statement. IMHO the location Berlin is always
>> GMT+1 independent of DST. In general DST does NOT affect the timezone. The
>> later is only affected by the location.
> Common explanations tend to differ from your view:
>   
I guess that this is due to some language inaccuracies.

> We would need to change the datetime definition then to include timezone
> information and we would need to come up with a good definition for timezone.
> As this forces a massive change on all clients, I believe we should propose 
> something for beyond the 2.0 spec, which is stable as it is (and having the 
> shortcomings that is has).
>   

I don't see the massive change as current clients seem not to really 
care or implement smart/correct timezone and DST handling.

>> Why is a recurring event like weekly on Mondays at 2pm a rare use case?
>>     
>
> Well, it is not. But people argued somehow that this was not happening
> due to calculations when the appointment was made.
>   
So how is a reccuring event which happens daily at noon expressed in our 
xml according to your view?

> I remembered testing this stuff Toltec and Kontact back and forth 
> and it used to work.
>   
Did you also cover events which got created before the DST change and 
then looked at them after the DST change?

Yours,
-- martin


From alan at collison.net  Tue Jun  3 17:23:52 2008
From: alan at collison.net (Alan J Collison)
Date: Tue, 03 Jun 2008 11:23:52 -0400 (EDT)
Subject: Timezone issues
Message-ID: <20080603152352.5FD94497D@arkroyal.cnchost.com>

A few comments:

1. It appears that the event shown below is not recurring. In that case, 
   time zone is irrelevant.  The start date-time in UTC 
   uniquely identifies when the event begins - i.e., 
   given whatever time zone you choose, you can derive
   the start time of the event given it's start time in UTC.
   So for this event, storing time zone information
   is entirely unnecessary.  Time zone info is important for
   recurring events, not for non-recurring events.

2. Probably just an issue of semantics, but DST does not change
   your time zone - it changes your offset from GMT.  My time
   zone designation is America/New_York, the Olson designation for
   the US East coast.  After a DST change, I'm still in the
   America/New_York time zone :)
   I can determine my current offset from the time zone information
   contained in my systems TZ data (which I believe for most, if not
   all, systems is based on the Olson DB nowadays).

3. For recurring events you *must* include time zone information for
   the time zone the event was created in,
   otherwise you're just saying "well, it will work *most* of the
   time."  If that's what you're shooting for then I guess that's
   fine, but the cases where this will fail without specifying
   time zone are more common than you might think and can
   change over time. As Martin noted, DST is a political thing and
   any locale can decide to observe it or not and arbitrarily decide
   how much to shift.  In the U.S., there are specific regions
   where the local governments decided to not observe DST even though
   most of the country does - and, at least one locale I know of
   changed just this past year.  

4. I do not see why you need to alter the datetime definition.
   datetime is always UTC, correct?  Just add the <time-zone/>
   tag and for God's sake use the Olson time zone designations :)
   It's true that iCalendar would allow the flexibility to
   specify different time zones for each date-time value, but in practice
   I have never seen any client do this.  Unlike DST, ignoring
   that possibility is a much safer bet.  Given the start time in
   UTC and the time zone designation for the event, then any client can
   determine the complete set of occurrences for the event
   regardless of what time zone it is viewed in (assuming, of course,
   the system the client is on has complete and updated
   TZ data).

   Any client which does not recognize the <time-zone/>
   tag is no worse off than it currently is I think.  For clients 
   that want to support this, they simply have to map whatever
   client TZ designations it has to the Olson designations (preferably).

Some documents here may be of interest:

http://www.calconnect.org/recommendations.shtml

Alan


---- Bernhard Reiter <bernhard at intevation.de> wrote:
>
> Hi Martin,
> 
> On Tuesday 03 June 2008 00:28, Martin Konold wrote:
> > >> When entering a date e.g. for an event KDE Kontact should use
> > >>
> > >> <time-zone>(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm,
> > >> Wien</time-zone>
> > >
> > > what do you mean by "entering" a date?
> >
> > I mean creating an event with the KDE Kontact (KOrganizer) UI.
> >
> > > (I've just tried Kontact 1.2.9 (enterprise 20080520.810305)
> > > and created an event and looked at the resultung Kolab-xml file,
> > > there is no <time-zone> tag in there.)
> >
> > This is the report from a user on Debian stable:
> 
> Which version of Kontact? 
> E.g. current and recommended is enterprise35 for Debian Etch.
> 
> > User-Agent: KONSEC Konnektor 1.1.8.1
> 
> > Content-Transfer-Encoding: quoted-printable
> > Content-Type: application/x-vnd.kolab.event; name=event.xml
> > Content-Disposition: attachment; filename=event.xml
> >
> > <?xml version=3D=221.0=22 encoding=3D=22UTF-8=22?>
> > <event version=3D=221.0=22>
> >    <product-id>KONSEC Konnektor 1.1.8.1 Build: Mar 17 2008</product-id>
> >    <netmeeting-type>0</netmeeting-type>
> >    <is-all-day-event>0</is-all-day-event>
> >    <show-time-as>busy</show-time-as>
> >    <meeting-status>0</meeting-status>
> >    <duration>30</duration>
> >    <response-status>0</response-status>
> >    <recurrence-type>0</recurrence-type>
> >    <time-zone>(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm,
> > Wien</time-zone> <-------- this does correctly not reflect DST
> >    <is-recurring>0</is-recurring>
> >    <conference-server-allow-external>1</conference-server-allow-external>
> >    <cal-unknown-0x8124>0</cal-unknown-0x8124>
> >    <cal-unknown-0x8224>-1</cal-unknown-0x8224>
> >    <cal-unknown-0x8256>0</cal-unknown-0x8256>
> >    <cal-unknown-0x8207>0</cal-unknown-0x8207>
> >    <cal-unknown-0x8257>0</cal-unknown-0x8257>
> >    <cal-unknown-0x8259>0</cal-unknown-0x8259>
> >    <cal-unknown-0x825a>0</cal-unknown-0x825a>
> >    <cal-unknown-0x8235>2008-05-13T16:00:00Z</cal-unknown-0x8235>
> >    <cal-unknown-0x8236>2008-05-13T16:30:00Z</cal-unknown-0x8236>
> >    <cal-unknown-0x8245>0</cal-unknown-0x8245>
> >    <cal-unknown-0x8201>0</cal-unknown-0x8201>
> >    <unknown-0x8510>369</unknown-0x8510>
> >    <unknown-0x8518>0</unknown-0x8518>
> >    <priority>0</priority>
> >    <sensitivity>public</sensitivity>
> >    <private>0</private>
> >    <summary>Test-Zeitverschiebung bei Terminen-aap</summary>
> >    <creation-date>2008-05-13T14:18:50Z</creation-date>
> >    <last-modification-date>2008-05-13T14:18:50Z</last-modification-date>
> >
> > This means that in this case the <time-zone> tag was added by the KONSEC
> > Konnektor. 
> 
> Did you miss copying the <start-date>?
> 
> > According to the Debian user this event is off-by-one hour in KDE Kontact.
> 
> It is hard to judge without the <start-date> line. :)
> A common mistake in Kontact configuration is that Settings -> Events -> 
> Date/Time is not set to the right timezone.
> 
> > >> Rational: The timezone is solely dependend on the geographic location
> > >> but not on the week. This is especially important for events spanning
> > >> over DST switching sundays.
> > >
> > > Well, both variants do not seem to be a nice specification of a
> > > time-zone, they both are wrong about half of the year.
> >
> > I tend to disagree with this statement. IMHO the location Berlin is always
> > GMT+1 independent of DST. In general DST does NOT affect the timezone. The
> > later is only affected by the location. 
> 
> Common explanations tend to differ from your view:
> 
> http://en.wikipedia.org/wiki/Daylight_saving_time#Observance_practices
>    In this example, a location observing UTC+10 during standard time is at 
> UTC+11 during DST; conversely, a location at UTC?10 during standard time is 
> at UTC?9 during DST.
> 
> http://de.wikipedia.org/wiki/Zeitzone#Sommerzeit
>    Viele L?nder wechseln in der Fr?hlingsmitte in eine andere Zeitzone, im 
> Herbst wieder zur?ck. So gilt in den meisten EU-Staaten im Winter die MEZ 
> (UTC+1h), in den Sommermonaten aber die mitteleurop?ische Sommerzeit (MESZ, 
> UTC+2h).
> 
> Roughly translated: Many countries switch into a different timezone mid spring 
> and back in the fall. So for most EU-countries it is MEZ (UTC+1h) in the 
> winter and middleeuropean sommertime in the sommer (MESZ UTC+1h). 
> 
> > > Currently we do not have "time-zone" in the specification.
> > > Are you proposing to add it?
> >
> > Yes. I propose to add <time-zone> to the specification and explicitly
> > stating the the adaption according to the DST has always to be handled in
> > the client while displaying not while storing.
> 
> We would need to change the datetime definition then to include timezone
> information and we would need to come up with a good definition for timezone.
> As this forces a massive change on all clients, I believe we should propose 
> something for beyond the 2.0 spec, which is stable as it is (and having the 
> shortcomings that is has).
> 
> > > (I would welcome this as I believe that there is a rare problem
> > > when specifying recurrent events, which we discussed years ago.)
> >
> > Why is a recurring event like weekly on Mondays at 2pm a rare use case?
> 
> Well, it is not. But people argued somehow that this was not happening
> due to calculations when the appointment was made.
> This reduced the problem to cases where you would do calculations on the 
> server with the clients having strange different daylightsaving time borders.
> Making it a rare case.
> 
> I remembered testing this stuff Toltec and Kontact back and forth 
> and it used to work.
> 
> > >> E.g. a daily recurring event at 12 noon like "lunch" shall always happen
> > >> at the same time and not be affected by daylight saving time switches.
> > >
> > > Correct means it should happen on the same time within the time zone,
> > > so in summer time it is always 12:00 (even when this is 11:00 or 10:00
> > > UTC depending on the daylight saving period it occurs in).
> >
> > Yes, and therefore the time stored permanently must be independent on DST
> > but dependent on explicit timezone.
> 
> You must know if daylight saving is used, yes.
> If you make "Berlin" the name of that zone including daylight saving,
> the "GMT+1" should be left out as it is wrong. Berlin will have GMT+1 and 
> GMT+2 depending on the DST. I think Unix's TZ= works like this.
> 
> > This is the only safe way to store an event like 12 noon at some
> > future date because DST rules are due to political reasons unpredictable
> > (only guessable).
> >
> > >> BTW: This is something which MS Outlook 2K3 does correct ;-)
> 
> I claim that the GMT+1 is clearly false for Berlin in the summer.
> 
> > > I believe Kontact does this correctly, though.
> > > If not please let us know the test case or directly file an issue
> > > in the tracker.
> >
> > The above mentioned customer claims that KDE Kontact in Debian stable
> > shifts the event by one hour in case the event got created with KONSEC
> > Konnektor.
> 
> This is seems a special case we might want to continue discussing on the users 
> list. (To comment someone would need the Kontact version, the original 
> <start-date> tag and the korganiserrc setting for timezone.)
> 
> Best,
> Bernhard
> -- 
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> 


From bernhard at intevation.de  Thu Jun 12 11:23:03 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 12 Jun 2008 11:23:03 +0200
Subject: Timezone issues
In-Reply-To: <484559FD.9040900@erfrakon.de>
References: <200805260954.05097.martin.konold@erfrakon.de>
	<200806031610.02131.bernhard@intevation.de>
	<484559FD.9040900@erfrakon.de>
Message-ID: <200806121123.06978.bernhard@intevation.de>

Hi Martin,

Am Dienstag, 3. Juni 2008 16:49:33 schrieb Martin Konold:
> Bernhard Reiter wrote:

> >> I tend to disagree with this statement. IMHO the location Berlin is
> >> always GMT+1 independent of DST. In general DST does NOT affect the
> >> timezone. The later is only affected by the location.
> >
> > Common explanations tend to differ from your view:
>
> I guess that this is due to some language inaccuracies.

Berlin timezone is GMT+2 in the summer,
so your statement above " the location Berlin is always GMT+1 independent of 
DST" is wrong to me.

> > We would need to change the datetime definition then to include timezone
> > information and we would need to come up with a good definition for
> > timezone. As this forces a massive change on all clients, I believe we
> > should propose something for beyond the 2.0 spec, which is stable as it
> > is (and having the shortcomings that is has).
>
> I don't see the massive change as current clients seem not to really
> care or implement smart/correct timezone and DST handling.

Alan J Collison had good points on this  in his last emails
so we should look into that "Olson time zone designations" and see
if this is workable. 

> >> Why is a recurring event like weekly on Mondays at 2pm a rare use case?
> >
> > Well, it is not. But people argued somehow that this was not happening
> > due to calculations when the appointment was made.
>
> So how is a reccuring event which happens daily at noon expressed in our
> xml according to your view?

I believe it is just expressed 
as current Kontact enterprise35 or proko2 writes it.
The argument did not fully come from my side - as I believed there was
a problem, which was not seen by others. It is in the email archives 
somewhere. You were among the active group as well back then.

> > I remembered testing this stuff Toltec and Kontact back and forth
> > and it used to work.
>
> Did you also cover events which got created before the DST change and
> then looked at them after the DST change?

Yes, of course, otherwise it would not have been a test for this issue. :)
I believe the problem comes up if we have clients which are in timezones
that have different days of switching the DST. Wenn this came up I personally 
did not follow through on the algorithm completely.

Best,
Bernhard


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-format/attachments/20080612/33cf4e7a/attachment.bin