Mailing List Archive

Handling of TZ info from Lotus Notes
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.

Questions:
- Is the TZ info in the inbound message correct?
- Is there anything I can do within davical to work around it and avoid
the error?
- Whatever the davical interpretation, it appears that Lightning and
iPhone clients interpret whatever it stored differently. Should this be
possible?

Many thanks for any advice...
Chris



Sanitised copy of the rest of the vcalendar message:

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:GMT -0000 (Standard) / GMT +0100 (Daylight)
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20110510T182358Z
DTSTART;TZID="GMT -0000 (Standard) / GMT +0100 (Daylight)":20110511T100000
SUMMARY:Rescheduled: xxxx (11 May 10:00 GDT in 4th Floor Kitchen - (altho
ugh I will try to find a meeting room))
UID:DA3A9DA099912D308025788A004FF82C-Lotus_Notes_Generated
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'xxx at xxxx.co.uk'":MAILTO:xxx at xxxx.co.uk
ORGANIZER;X-SENTBYCN="xxx
xxx";SENT-BY="MAILTO:xxx at xxx.co.uk";CN="xxx/UK/IBM":MAILTO:xxx at uk.ibm.com
LOCATION:4th Floor Kitchen - (although I will try to find a meeting room)
DTEND;TZID="GMT -0000 (Standard) / GMT +0100 (Daylight)":20110511T110000
DESCRIPTION:From: xxx/UK/IBM [mailto:xxx at uk.ibm.com] \NSen
t: 10 May 2011 7:24 PM\NTo: xxxxxx\NSubject: xxx (11 May
10:00 GDT in 4th Floo
r Kitchen - (although I will try to find a meeting room))\NWhen: 11
May 20
11 10:00 AM-11:00 AM (GMT) Greenwich Mean Time : Dublin\, Edinburgh\, Lisb
on\, London.\NWhere: 4th Floor Kitchen - (although I will try to
find a me
eting room)\N\NDescription xxx.\N <<ATT533846.htm>> <<ATT533847.htm>>
<<c193401.ics>> \N
SEQUENCE:1
PRIORITY:5
CLASS:
CREATED:20110511T081439Z
LAST-MODIFIED:20110511T081453Z
STATUS:CONFIRMED
TRANSP:OPAQUE
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-CDO-REPLYTIME:20110509T105200Z
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
ATTACH:CID:001b01cc0fb3$81e0d803$_CDOEX
ATTACH:CID:001c01cc0fb3$81e0d803$_CDOEX
ATTACH:CID:001d01cc0fb3$81e0d803$_CDOEX
X-MICROSOFT-CDO-OWNERAPPTID:-1
X-MICROSOFT-CDO-APPT-SEQUENCE:1
X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20110511T081439Z
X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20110510T182358Z
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT00H15M00S
END:VALARM
END:VEVENT
END:VCALENDAR
Handling of TZ info from Lotus Notes [ In reply to ]
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-users/attachments/20110516/cea490e8/attachment.pgp>
-------------- next part --------------