Recurring meeting offset an hour

[Jim West]

I'm using DavMail 5.1 with Thunderbird 60 on a Debian "Buster" Linux system. The Thunderbird/Lightning and DavMail versions installed are those provided by the Debian repository. I recently sent out an invitation for a recurring meeting through the DavMail interface, which seemed to go fine, but when I started getting acceptances they listed the time as an hour later. The people who received the invitations confirmed that it went into their calendars delayed by an hour. Are there any nuances with my setup that I need to be aware of to avoid this? I'll note that the recurrance period started when we are on daylight savings time but ended when we'll be back in standard time, in case that matters.

Thanks for any help that can be provided.

[Mickael Guessant]

There should not be any difference between meetings and simple calendar events on timezone.
What happens when you create a recurring event, is the event timezone correct in OWA ?

In order to help Exchange convert event, DavMail tries to map incoming TZID to Exchange value:
https://svn.code.sf.net/p/davmail/code/trunk/src/java/exchtimezones.properties

Can you please if this table is correct in your case ?

[Gurce]

Hi Jim. I was wondering where are you based? I am in Sydney Australia. I'm kind-of experiencing the opposite to you, a colleague creates a recurring event, I accept, they later change a single instance of the event (let's say in a particular month) to a different datetime. When I try to accept this, it fails, and there's a mismatch on the new time he specified and the new time showing on my side of about an hour.

Part of me wonders if it relates to Sydney switching between two timezones due to daylight savings?

From first Sunday of October to first Sunday of April
AEDT: UTC+11:00 (Australian Eastern Daylight Time)

For the rest of the year
AEST: UTC+10:00 (Australian Eastern Standard Time)

Usually, for the 2nd notification in Thunderbird, I see a mention that the timezone specified is for Brisbane time (Brisbane, Queensland only use AEST time throughout the whole year).

More official info on Australia's daylight savings system here:
https://info.australia.gov.au/about-australia/facts-and-figures/time-zones-and-daylight-saving

I noticed in the "exchtimezones.properties" file that Mickael mentioned, it only had these entries relating to Australia:

Australia/Adelaide=Cen. Australia Standard Time
Australia/Brisbane=E. Australia Standard Time
Australia/Darwin=AUS Central Standard Time
Australia/Hobart=Tasmania Standard Time
Australia/Melbourne=AUS Eastern Standard Time
Australia/Perth=W. Australia Standard Time

I'm guessing Sydney would share the same mapping as Melbourne (they both partake in this daylight savings system), but it's interesting how on that line highlighted above, AEST (AUS Eastern Standard Time) is enforced, and it makes me wonder if davmail is not aware of AEDT/daylight savings, and whether that could be part of the problem.

[Mickael Guessant]

DavMail does not handle dates directly, it mostly passes date values unchanged to Exchange/O365.

In Caldav each event contains timezone definition, including DST. However this definition is not used by Exchange/O365 most of the time. This is the reason why DavMail tries to convert incoming TZID values to native Exchange TZIDs

Currently the mapping from Exchange to client for Australia is:

AUS\ Central\ Standard\ Time=Australia/Darwin
AUS\ Eastern\ Standard\ Time=Australia/Melbourne
Cen.\ Australia\ Standard\ Time=Australia/Adelaide
E.\ Australia\ Standard\ Time=Australia/Brisbane
Tasmania\ Standard\ Time=Australia/Hobart
W.\ Australia\ Standard\ Time=Australia/Perth

Mapping from client to Exchange for Australia is:

Australia/Adelaide=Cen. Australia Standard Time
Australia/Brisbane=E. Australia Standard Time
Australia/Darwin=AUS Central Standard Time
Australia/Hobart=Tasmania Standard Time
Australia/Melbourne=AUS Eastern Standard Time
Australia/Perth=W. Australia Standard Time

I checked timezone definition received from Exchange :

BEGIN:VTIMEZONE
TZID:E. Australia Standard Time
BEGIN:STANDARD
DTSTART:16010101T000000
TZOFFSETFROM:+1000
TZOFFSETTO:+1000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T000000
TZOFFSETFROM:+1000
TZOFFSETTO:+1000
END:DAYLIGHT
END:VTIMEZONE

And

BEGIN:VTIMEZONE
TZID:AUS Eastern Standard Time
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=4
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=10
END:DAYLIGHT
END:VTIMEZONE

This seems to be correct.

According to your feedback, issues happen mainly with meetings coming from someone else, can you please confirm ?

At the moment I don't have enough elements to reproduce the issue.

[Gurce]

Hi Mickael,
Thanks for your response, and sorry for the delays getting back to you. I knew I would once I found a window to do so, and my calendar issues aggravated me enough to give me even more incentive to do so :)

I must admit that all this icalendar,tzid,ics stuff is a little foreign to me, so I've been doing some googling to get up to speed with this, to try get on the same page as you with your message.

On your trailing question, yes, I've mainly noticed this with other colleagues meeting requests, but perhaps that's due to me rarely making meeting requests myself. I had a review of my log notes of past things I tried with a colleague, and it seems that we did see some weirdness when I tried to create events too. From his perspective (in his Outlook client), it appeared that I had created the event in Australia/Brisbane timezone and his client had to re-adjust to Australia/Sydney.

My client is Thunderbird. Within it, I set the calendar's timezone to "Australia/Sydney", so perhaps it isn't Davmail, but Thunderbird? Really not sure at this stage.

I thought I might try change my Thunderbird timezone to be "Australia/Melbourne", to see if that will behave any better.

Also, I tried to see if there'd be any clues in the thunderbird calendar's source code. I noticed this file there:

https://hg.mozilla.org/comm-central/file/tip/calendar/timezones/zones.json

"Australia/Sydney": {
  "ics": [
    "BEGIN:STANDARD\r\nTZOFFSETFROM:+1100\r\nTZOFFSETTO:+1000\r\nTZNAME:AEST\r\nDTSTART:19700405T030000\r\nRRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU\r\nEND:STANDARD",
    "BEGIN:DAYLIGHT\r\nTZOFFSETFROM:+1000\r\nTZOFFSETTO:+1100\r\nTZNAME:AEDT\r\nDTSTART:19701004T020000\r\nRRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1SU\r\nEND:DAYLIGHT"
  ],
  "latitude": "-0335200",
  "longitude": "+1511300"
},

My eyes aren't acclimatised to interpreting all these details yet, but who knows, maybe you might notice something there?

[Gurce]

Hmm, I tried comparing the content within that VTIMEZONE chunk (for TZID="AUS Eastern Standard Time") against what I saw in that code-snippet from thunderbird-calendar's "zones.json" file:

I noticed one interesting difference:

• Exchange's VTIMEZONE contains that TZID field
• Thunderbird's zones.json doesn't have this, but instead embeds a TZNAME field into each BEGIN/END group.

STANDARD has TZNAME: AEST
DAYLIGHT has TZNAME: AEDT

Don't really know if this is any great revelation or not, but thought I'd just make a note of it.

[Gurce]

Hmm, I'm wondering, is there any logging facility that I can turn on within DavMail that will show me the guts of that ics information that Thunderbird will try push to davmail when I create an event?

I'd like to inspect that information and see what TZID value (if any) it puts there. Maybe that might provide me a clue.

[Gurce]

Hmm, inside Thunderbird's Error Console, I was occasionally seeing warnings relating to these ics chunks.

While my thunderbird was set to "Australia/Melbourne" timezone, this error-console output made mention that TZID equaled "Australia/Melbourne".

Later, I switched thunderbird back to "Australia/Sydney" timezone, and then I saw in the error-console that TZID equaled "Australia/Brisbane" :(

So perhaps for now, until I can dig deeper into this, I'll stick with the "Australia/Melbourne" timezone and see if I fare any better with that.