Incorrect time zone offset being applied for India (Asia/Kolkata)
I do not know if this is the correct place to report this bug, but it seems to be related to applications using evolution-data-server as their calendar backend (I tested with Evolution and GNOME Calendar). When the system time zone is Asia/Kolkata (IST, UTC+05:30), an event created using this time zone uses an incorrect time zone offset of UTC+05:21:10 instead. More precisely, an obsolete time zone offset that was only used before 1906! From the relevant portion of tzdata/asia:
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone Asia/Kolkata 5:53:28 - LMT 1854 Jun 28 # Kolkata
5:53:20 - HMT 1870 # Howrah Mean Time?
5:21:10 - MMT 1906 Jan 1 # Madras local time
5:30 - IST 1941 Oct
5:30 1:00 +0630 1942 May 15
5:30 - IST 1942 Sep
5:30 1:00 +0630 1945 Oct 15
5:30 - IST
Clearly, there is no reason why the event should be recorded with the MMT time zone instead of the correct UTC+05:30 IST, and yet, somehow it is. Interestingly, GNOME Shell itself seems to be using the correct time zone, and thus in its drop-down calendar in the top bar, any event created with the Asia/Kolkata time zone is displayed with an offset of 5:30 - 5:21:10 = 8m:50s added to it (another side effect of this is that all day events span two consecutive days).
To replicate this bug, do either of the following:
If using the GNOME Calendar app:
- First set the system time zone to Asia/Kolkata
- Open Calendar, and create a new event, and set the start time to any value, say 10:00
- Check the calendar view in the top bar. The time of the event just created will be 10:08
If using Evolution:
- Open Evolution, and create a new appointment as above.
- Under the Time zone field, choose Asia/Kolkata (and notice the weird time zone offset in the selection window).
- Save the appointment, and as in the previous case, notice the mismatch between the time of the event recorded with the messed up time zone and the time in the UTC+05:30 offset of IST.
I also exported an ics of one such event, hoping it might offer some clue:
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:/freeassociation.sourceforge.net/Asia/Kolkata
X-LIC-LOCATION:Asia/Kolkata
BEGIN:STANDARD
TZNAME:MMT
DTSTART:20060202T062816
TZOFFSETFROM:+055320
TZOFFSETTO:+052110
RRULE:FREQ=YEARLY;UNTIL=20060207T010706Z;BYDAY=1TU;BYMONTH=2
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:+0630
DTSTART:19420907T000000
TZOFFSETFROM:+0530
TZOFFSETTO:+0630
RRULE:FREQ=YEARLY;UNTIL=19410930T130000Z;BYDAY=1TU;BYMONTH=9
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:bb2dc6e58ea19a78b5d30617a9aff1507316963b
DTSTAMP:20210727T071306Z
DTSTART;TZID=/freeassociation.sourceforge.net/Asia/Kolkata:
20210727T105200
DTEND;TZID=/freeassociation.sourceforge.net/Asia/Kolkata:20210727T235100
SUMMARY:Test1
SEQUENCE:25
CREATED:20210727T071336Z
LAST-MODIFIED:20210727T171018Z
DESCRIPTION:A test event
TRANSP:OPAQUE
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR
~
In short, for some reason, evolution is incorrectly parsing the tzdata rules for Asia/Kolkata (and probably some other locations too, I assume), leading to all sorts of troublesome behaviour.
This bug is present in Ubuntu 21.04. Also in Fedora 34. I tested with the live CD of Ubuntu 20.10, and the bug was not present there, so some recent change in some package has led to this.