bernhard at intevation.de
Thu Jun 12 11:23:03 CEST 2008
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.
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...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the format