Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Event Time Offset

  • 3 replies
  • 1 has this problem
  • 16 views
  • Last reply by Kasey

more options

Since updating to Supernova (115.4.1 64-bit Windows 10), we have encountered many issues with the schedule time of the calendar event invitation. We noticed that it's offset by 40 minutes. By the way, we are in UTC+8 (Malaysia Time Zone) and the calendar is sync thru Icewarp (115.4.1)'s CalDAV. One event received in Yahoo! Mail is even worse; offset to 18 hours earlier. How can we troubleshoot this issue. We are very sure that the issue is caused by Thunderbird as the inviter using CalDAV. Thank you.

Since updating to Supernova (115.4.1 64-bit Windows 10), we have encountered many issues with the schedule time of the calendar event invitation. We noticed that it's offset by 40 minutes. By the way, we are in UTC+8 (Malaysia Time Zone) and the calendar is sync thru Icewarp (115.4.1)'s CalDAV. One event received in Yahoo! Mail is even worse; offset to 18 hours earlier. How can we troubleshoot this issue. We are very sure that the issue is caused by Thunderbird as the inviter using CalDAV. Thank you.
Attached screenshots

All Replies (4)

more options

To be honest, I would suggest you look at the ical files containing the invitations (crtl+U) will give access to the message source. Are the UTC offsets in the calendar invite correctly set for the expected time an date?

I would suspect at least someone is setting the time on their computer and not the UTC offset or timezone correctly, depending on which operating system they use.

The 40 minutes however is very odd. That sounds like the time is set on the server but the timezone is not correct, except 40 minutes does not equate to any timezone "change" I am aware of. while there are a number of time zones that are on the 30 and 45 minute mark 40 is an oddity.

Could this be an issue arising from changes in base calendar from gregorian to another and back again? I do not claim any sort of expertise, but I think if it is a bug it needs to be isolated as to cause and at this point we have nothing.

more options

Below is the content of the ics file. I have checked with Icewarp and they denied it's their server issue.

BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Asia/Kuala_Lumpur BEGIN:STANDARD TZOFFSETFROM:+0730 TZOFFSETTO:+0800 TZNAME:Asia/Kuala_Lumpur(STD) DTSTART:19701231T233000 RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=12;BYMONTHDAY=31 END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0700 TZOFFSETTO:+0720 TZNAME:Asia/Kuala_Lumpur(DST) DTSTART:19700101T000000 RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=1;BYMONTHDAY=1 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT CREATED:20231102T083448Z LAST-MODIFIED:20231102T083448Z DTSTAMP:20231102T083448Z UID:6262a316-cb8b-426c-8c45-1c01b0fab018 SUMMARY:1600 - 1700 Thunderbird PRIORITY:0 ORGANIZER:mailto:iqbal@abc.com ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:woo.kc

@abc.com

ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:zalina

@abc.com

DTSTART;TZID=Asia/Kuala_Lumpur:20231102T160000 DTEND;TZID=Asia/Kuala_Lumpur:20231102T170000 DESCRIPTION:1600 - 1700 Thunderbird X-SERVER-UID:65435f27bda7 SEQUENCE:0 CLASS:PUBLIC X-MICROSOFT-CDO-BUSYSTATUS:busy TRANSP:OPAQUE END:VEVENT END:VCALENDAR

Matt said

To be honest, I would suggest you look at the ical files containing the invitations (crtl+U) will give access to the message source. Are the UTC offsets in the calendar invite correctly set for the expected time an date? I would suspect at least someone is setting the time on their computer and not the UTC offset or timezone correctly, depending on which operating system they use. The 40 minutes however is very odd. That sounds like the time is set on the server but the timezone is not correct, except 40 minutes does not equate to any timezone "change" I am aware of. while there are a number of time zones that are on the 30 and 45 minute mark 40 is an oddity. Could this be an issue arising from changes in base calendar from gregorian to another and back again? I do not claim any sort of expertise, but I think if it is a bug it needs to be isolated as to cause and at this point we have nothing.
more options

This issue started since upgrading to supernova (115). The event received will be offset by 40 minutes. Finally I tried to use an older version of Thunderbird and I have found the difference within the VTIMEZONE in the ICS file.

Prior to Supernova:- BEGIN:VTIMEZONE TZID:Asia/Kuala_Lumpur BEGIN:STANDARD TZOFFSETFROM:+0800 TZOFFSETTO:+0800 TZNAME:+08 DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE

Supernova:- BEGIN:VTIMEZONE TZID:Asia/Kuala_Lumpur BEGIN:STANDARD TZOFFSETFROM:+0730 TZOFFSETTO:+0800 TZNAME:Asia/Kuala_Lumpur(STD) DTSTART:19701231T233000 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYMONTH=3D12;BYMONTHDAY=3D31 END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0700 TZOFFSETTO:+0720 TZNAME:Asia/Kuala_Lumpur(DST) DTSTART:19700101T000000 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYMONTH=3D1;BYMONTHDAY=3D1 END:DAYLIGHT END:VTIMEZONE

Could this be the root cause to the irregular event schedules? Thanks in advance.

Modified by Kasey

more options

I have noticed that there is something different in the timezone. Could this be the fault? By the way, Kuala Lumpur never have daylight savings.

Extract from event created by Thunderbird prior to Supernova:- BEGIN:VTIMEZONE TZID:Asia/Kuala_Lumpur BEGIN:STANDARD TZOFFSETFROM:+0800 TZOFFSETTO:+0800 TZNAME:+08 DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE

Extract from event created by Thunderbird Supernova:- BEGIN:VTIMEZONE TZID:Asia/Kuala_Lumpur BEGIN:STANDARD TZOFFSETFROM:+0730 TZOFFSETTO:+0800 TZNAME:Asia/Kuala_Lumpur(STD) DTSTART:19701231T233000 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYMONTH=3D12;BYMONTHDAY=3D31 END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0700 TZOFFSETTO:+0720 TZNAME:Asia/Kuala_Lumpur(DST) DTSTART:19700101T000000 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYMONTH=3D1;BYMONTHDAY=3D1 END:DAYLIGHT END:VTIMEZONE