Bugzilla – Bug 1212693
Incorrect time spanning of the all-day event on gnome shell calendar.
Last modified: 2023-08-11 07:40:35 UTC
Created attachment 867810 [details] Summer Solstice. On GNOME Shell Calendar (on the topbar), the time spanning to 48 hours for a normal all-day event. I experienced this when using Office 365 mail suite, but I suspect this can be a general issue for the calendar handling the all-day event in ical format. Here is the step I tried: 1. Install evolution-ews and configure an Office 365 account (e.g. I used the company's setup in my case https://confluence.suse.com/display/LITC/Email+client+configuration+for+Modern+Authentication#EmailclientconfigurationforModernAuthentication-Evolution) 2. Sync the calendar to Evolution, and check a random all-day event in the Evolution Calendar. For example, Summer Solstice appears fine in the Calendar as an exact 24 hour event on 21/Jun/2023. 3. However, on the GNOME Shell top bar, check the same date through the calendar. The event is there but it will span in 48 hours including a day ahead of the correct date. For example, the Summer Solstice will be shown on both 20/Jun and 21/Jun. As the screenshot told, the all-day event of Summer Solstice is clearly spanned and shown in both 20/Jun to 21/Jun.
As this issue is not seen in GNOME Calendar (the app) or Evolution, it appears to me only on gnome-shell-calendar. Let me put it on GNOME Shell's queue by now, though the problem maybe spawn somewhere in GNOME Shell, evolution-data-calendar or libical upstream. Xiaoguang, can you take a look please? Thanks.
To avoid timezone calculation mismatching confusion, to reproduce this, I manually set all the timezone as same as the place I physically located (UTC+8): 1. Office 365 server side time zone 2. Evolution client time zone 3. Gnome Settings system time zone 4. timedatectl on systemd
The issue occurs with time zone "Asia/Beijing". The time zone "Asia/Beijing" was added by openSUSE in the timezone package, but it is not included in the IANA TZ database. The Calendar in gnome-shell is written in JavaScript, and the JavaScript engine uses the ICU API to handle time and date. The ICU package depends on a database file in the libicu73-ledata package to handle time and date. This database file does not include the time zone "Asia/Beijing", so gnome-shell will get the wrong time and date for calendar events with that time zone. The database file was created by upstream based on the IANA TZ database, so we cannot modify it to add "Asia/Beijing" on OBS.
Asia/Beijing was SUSE-specific and has already been replaced; there is a not too old remark in yast2-country source code about this: it "fixes obsolete Chinese timezones (bsc#1190586)" do expect(subject.UpdateTimezone("Asia/Beijing")).to eq "Asia/Shanghai" expect(subject.UpdateTimezone("Asia/Harbin")).to eq "Asia/Shanghai" end Nobody should be using Asia/Beijing anymore I guess. Just ln -fs /usr/share/zoneinfo/Asia/Shanghai /etc/localtime to update your zone, if it still is Beijing. That makes the ICU change unnecessary.
My two cents: I checked the information from the internet and found that the use of Beijing time is a habit and there is no mandatory explicit legal norm. there's no harm to use "Asia/Shanghai" timezone. which means no necessary to add Asia/Beijing. http://beijing.toupailvshi.com/question/5C504cB5.html https://github.com/bminor/glibc/blob/master/timezone/asia (line:295)
I test the latest Tumbleweed ISO, on the time zone selection option, We can't see the option for the Beijing time zone anymore. So I suggest to remove the patch tzdata-china.diff in timezone package, This patch added the Asia/Beijing time zone to openSUSE. Removing this patch will prevent users from accidentally selecting the Asia/Beijing time zone, which could lead to confusion.
(In reply to xiaoguang wang from comment #6) > I test the latest Tumbleweed ISO, on the time zone selection option, That's when installing a new system, I can't see the Asia/Beijing time zone selection.