After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 786158 - Don't use an iCalendar DATE value type for midnight!!
Don't use an iCalendar DATE value type for midnight!!
Status: RESOLVED OBSOLETE
Product: gnome-calendar
Classification: Applications
Component: General
3.24.x
Other Linux
: Normal major
: 3.26
Assigned To: GNOME Calendar maintainers
GNOME Calendar maintainers
Depends on:
Blocks:
 
 
Reported: 2017-08-11 15:04 UTC by Stephen
Modified: 2017-11-24 22:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stephen 2017-08-11 15:04:14 UTC
Creating an event starting at a time equivalent to midnight UTC results in a VEVENT in an iCalendar calendar like the following:

DTSTART;VALUE=DATE:20170818
DTEND:20170818T010000Z

The above was the result of creating an event for 01:00-02:00 in Europe/London (UTC+1 at the moment).

This is totally wrong. It should be a DATE-TIME, like the end time above. The above start time is effectively a floating time, so now you have an event with a floating start time and time zone-anchored end time.

I couldn't find anything explicit in the RFC about interpretation of a DATE value used in this way, but given the absence of time zone specification in a DATE value, the value would be most sensibly interpreted as a floating time of 00:00.

That means another client would reasonably interpret the above as "starts at 00:00 local time, ends at 00:00 UTC". In fact that is what Evolution does - it's interpreted as 00:00-02:00 Europe/London (UTC+1).

Event DTEND seems to always be a DATE-TIME - only DTSTART seems to have this broken behaviour.
Comment 1 Stephen 2017-08-11 15:14:33 UTC
Oh god, there's more. So in the above example Calendar is writing the DATE DTSTART as if it means "UTC midnight" (i.e. T000000Z). But then, when the start is edited in Calendar, it is written out as a *floating* time. E.g. changing the start time to 02:00 on a Europe/London system (currently UTC+1) results in:

DTSTART:20170819T010000
DTEND:20170819T010000Z

So now the start is *explicitly* floating per RFC 5545, but the end is still UTC (anchored).

But wait, there's even more. Now, when the *end time* is changed, it also gets converted to floating time. For example changing it to 03:00 Europe/London (UTC+1) results in:

DTSTART:20170819T010000
DTEND:20170819T020000
Comment 2 Georges Basile Stavracas Neto 2017-11-24 22:34:37 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-calendar/issues/172.