On Wed, 2011-05-11 at 10:36 +0100, Chris Palmer wrote:
> Davical is working well for me. However I have one oddity now that I am
> receiving meeting invitations originating from Lotus Notes. They are
> coming into a MS Exchange system, and I am forwarding them to my davical
> server (on Linux FC14, Apache 2.2.17, php 5.3.4, davical 0.9.9.4, awl
> 0.46) for use with Thunderbird 3.1.10/Lightning 1.0b2 and iPhone4 4.3
> clients.
>
> The problem started when the UK switched to summer time (GMT+1, aka
> GDT). An inbound invitation update this morning contained:
>
> DTSTART;TZID="GMT -0000 (Standard) / GMT +0100 (Daylight)":20110511T100000
> DTEND;TZID="GMT -0000 (Standard) / GMT +0100 (Daylight)":20110511T110000
>
> On processing this davical logged
> [Wed May 11 09:22:27 2011] [error] [client x.x.x.x] davical: ***: ERROR:
> Couldn't guess Olsen TZ from TZID[GMT]. This may end in tears...
>
> On the Exchange system and in Lightning, the meeting appears at 10-11,
> but on the iPhone it is at 11-12.
DAViCal tries to work out an Olsen timezone name from incoming data, and
that's *generally* a successful trick. Olsen names are things like
"Europe/London", "America/Buenos_Aires" or "Pacific/Auckland", and are
used pretty much exclusively by everyone except Microsoft (though they
do understand them).
DAViCal's log message means that DAViCal didn't understand the timezone
reference, and so it gives up.
Giving up is an OK thing for DAViCal to do, since very little usually
depends on DAViCal understanding the timezone. Most clients request all
of the data and maintain a local cache of some kind, and do all of the
parsing and calculations about this kind of thing themselves, so it
doesn't usually matter terribly much if DAViCal doesn't understand quite
exactly when an event is happening.
However it looks like the iPhone *also* doesn't understand that timezone
(DAViCal just supplies the timezone definition it received, along with
the event when it passes it out to a device). Not much I can do about
that, and even if DAViCal *did* understand it, the event on the iPhone
would probably still show up at the wrong time.
> Questions:
> - Is the TZ info in the inbound message correct?
Technically, it is correct.
> - Is there anything I can do within davical to work around it and avoid
> the error?
There's some code in DAViCal where it tries to match the incoming
timezone record against something it understands. You could add a line
in there to recognize it (there is code there already showing how to do
that), but it don't believe it will affect your iPhone experience at
all.
> - Whatever the davical interpretation, it appears that Lightning and
> iPhone clients interpret whatever it stored differently. Should this be
> possible?
Some software actually parses those timezone definitions, which was how
it was originally designed to be used, but pretty much everyone involved
in the design of the specification now believes that is a misguided
approach, and they should be *recognised* instead. A new revision of
the VTIMEZONE specification will come out in due course in which the
main body of the VTIMEZONE is optional, and a reference URI for the
timezone definition is supplied where it may be fetched from if it is
unknown.
The reasons for that are complex, but they're mainly due to the fact
that various legislative organisations decide to change the definitions
of these things without going back to all existing events and rewriting
them to match! Shocking, I know, but there we are :-)
I have it in my mind to implement the new timezone server specification
within DAViCal (when the round tuits start piling up on my desk) and at
that point we might try and add some more comprehensive recognition code
into DAViCal, and (possibly, optionally) rewrite such timezones on the
way through. That's really the only actual comprehensive solution.
Recognising these timezones is *really* hard, since Microsoft have
decided to localise the names of them all. In Portugal the same
timezone would probably use Portuguese words for "Standard" and
"Daylight", I believe relatively simple, you say, but perhaps the
meeting also involved a person dialing in from Israel, where the name of
the timezone has been localised to Hebrew. Sigh.
There's better luck recognizing the timezone from the rules it uses for
switching into / out of DST, of course, but as the rules change errors
might happen there, too. Fundamentally that's the best approach though.
In this case, for example we can say:
(a) The STANDARD offset is +0000
(b) The STANDARD offset starts late in each year
Even with just that much information it's probably possible to narrow it
down to one of just a few timezones, and if there are more than one then
we could start comparing the actual dates for onset of DAYLIGHT/STANDARD
so hopefully we'd have an answer quickly.
If we can apply such logic in DAViCal after the current name searching
logic fails we really don't mind too much if it's expensive, and we
could also use (potentially) use that as an indication to change the
TZID so clients didn't have to do such work.
> Many thanks for any advice...
Well, I don't imagine this has been incredibly helpful, but perhaps you
may now consider yourself better-informed on some of the issues :-(
Cheers,
Andrew.
--
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
The truth is rarely pure, and never simple. -- Oscar Wilde
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.davical.org/pipermail/davical-dev/attachments/20110516/cea490e8/attachment.pgp>
> Davical is working well for me. However I have one oddity now that I am
> receiving meeting invitations originating from Lotus Notes. They are
> coming into a MS Exchange system, and I am forwarding them to my davical
> server (on Linux FC14, Apache 2.2.17, php 5.3.4, davical 0.9.9.4, awl
> 0.46) for use with Thunderbird 3.1.10/Lightning 1.0b2 and iPhone4 4.3
> clients.
>
> The problem started when the UK switched to summer time (GMT+1, aka
> GDT). An inbound invitation update this morning contained:
>
> DTSTART;TZID="GMT -0000 (Standard) / GMT +0100 (Daylight)":20110511T100000
> DTEND;TZID="GMT -0000 (Standard) / GMT +0100 (Daylight)":20110511T110000
>
> On processing this davical logged
> [Wed May 11 09:22:27 2011] [error] [client x.x.x.x] davical: ***: ERROR:
> Couldn't guess Olsen TZ from TZID[GMT]. This may end in tears...
>
> On the Exchange system and in Lightning, the meeting appears at 10-11,
> but on the iPhone it is at 11-12.
DAViCal tries to work out an Olsen timezone name from incoming data, and
that's *generally* a successful trick. Olsen names are things like
"Europe/London", "America/Buenos_Aires" or "Pacific/Auckland", and are
used pretty much exclusively by everyone except Microsoft (though they
do understand them).
DAViCal's log message means that DAViCal didn't understand the timezone
reference, and so it gives up.
Giving up is an OK thing for DAViCal to do, since very little usually
depends on DAViCal understanding the timezone. Most clients request all
of the data and maintain a local cache of some kind, and do all of the
parsing and calculations about this kind of thing themselves, so it
doesn't usually matter terribly much if DAViCal doesn't understand quite
exactly when an event is happening.
However it looks like the iPhone *also* doesn't understand that timezone
(DAViCal just supplies the timezone definition it received, along with
the event when it passes it out to a device). Not much I can do about
that, and even if DAViCal *did* understand it, the event on the iPhone
would probably still show up at the wrong time.
> Questions:
> - Is the TZ info in the inbound message correct?
Technically, it is correct.
> - Is there anything I can do within davical to work around it and avoid
> the error?
There's some code in DAViCal where it tries to match the incoming
timezone record against something it understands. You could add a line
in there to recognize it (there is code there already showing how to do
that), but it don't believe it will affect your iPhone experience at
all.
> - Whatever the davical interpretation, it appears that Lightning and
> iPhone clients interpret whatever it stored differently. Should this be
> possible?
Some software actually parses those timezone definitions, which was how
it was originally designed to be used, but pretty much everyone involved
in the design of the specification now believes that is a misguided
approach, and they should be *recognised* instead. A new revision of
the VTIMEZONE specification will come out in due course in which the
main body of the VTIMEZONE is optional, and a reference URI for the
timezone definition is supplied where it may be fetched from if it is
unknown.
The reasons for that are complex, but they're mainly due to the fact
that various legislative organisations decide to change the definitions
of these things without going back to all existing events and rewriting
them to match! Shocking, I know, but there we are :-)
I have it in my mind to implement the new timezone server specification
within DAViCal (when the round tuits start piling up on my desk) and at
that point we might try and add some more comprehensive recognition code
into DAViCal, and (possibly, optionally) rewrite such timezones on the
way through. That's really the only actual comprehensive solution.
Recognising these timezones is *really* hard, since Microsoft have
decided to localise the names of them all. In Portugal the same
timezone would probably use Portuguese words for "Standard" and
"Daylight", I believe relatively simple, you say, but perhaps the
meeting also involved a person dialing in from Israel, where the name of
the timezone has been localised to Hebrew. Sigh.
There's better luck recognizing the timezone from the rules it uses for
switching into / out of DST, of course, but as the rules change errors
might happen there, too. Fundamentally that's the best approach though.
In this case, for example we can say:
(a) The STANDARD offset is +0000
(b) The STANDARD offset starts late in each year
Even with just that much information it's probably possible to narrow it
down to one of just a few timezones, and if there are more than one then
we could start comparing the actual dates for onset of DAYLIGHT/STANDARD
so hopefully we'd have an answer quickly.
If we can apply such logic in DAViCal after the current name searching
logic fails we really don't mind too much if it's expensive, and we
could also use (potentially) use that as an indication to change the
TZID so clients didn't have to do such work.
> Many thanks for any advice...
Well, I don't imagine this has been incredibly helpful, but perhaps you
may now consider yourself better-informed on some of the issues :-(
Cheers,
Andrew.
--
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
The truth is rarely pure, and never simple. -- Oscar Wilde
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.davical.org/pipermail/davical-dev/attachments/20110516/cea490e8/attachment.pgp>