GNOME Bugzilla – Bug 341348
Interpret date-only dates in calendar:// URL as in the local zone
Last modified: 2015-06-15 11:02:59 UTC
That bug has been described on https://launchpad.net/distros/ubuntu/+source/gnome-panel/+bug/42115 "When I double-click on any given date in the calendar applet, it consistently opens up Evolution to the day before the day I clicked (that is, if I click on the 25th, it opens the 24th, always). ..." The issue seems be due to the timezone configuration and happens with calling "evolution calendar:///?startdate=$(date +"%Y%m%dT%H%M%SZ")" too
that bug is discussed on launchpad, the issue is that it looks like "YYYYMMDD" is interpreted as YYYYMMDD at 00:00 GMT and evolution does the translation according to the timezome. Is there any documentation stating somewhere how "YYYYMMDD" without hour specification should be interpreted?
as i pointed out in the Ubuntu bug report, this bug is not valid. gnome-panel needs to specify the correct time/time zone. all valid dates require a day component and a time/time zone component. if no time or time zone is specified, Evolution quite reasonably assumes 00:00 GMT. for example, i am in the US Eastern time zone, which is GMT minus 4 hours. i give the command: evolution calendar:///?startdate=20060608 since no time is specified as part of the date, 00:00 is assumed. since no time zone is specified, GMT is assumed. thus, the date specified is 8 June 00:00 GMT and therefore 7 June 20:00 EDT. it appears that evolution is opening on the wrong date, when actually evolution is opening on the date specified. you can make the argument that the current time zone should be used in the case that the time zone is ommitted, but that would break the existing contract. i haven't looked at the code, but i assume that evolution uses a standard library to parse the date string. therefore, it is not reasonable to expect that evolution customize this. additionally, changing the semantics would break the existing valid (if implied) contract. finally, those who write scripts have a right to expect that dates be interpreted consistently across applications. if there is currently no way to specify the time zone with the command, that would be a legitimate RFE, so long as the new syntax does not break existing scripts.
as said on the distribution bug, I would expect "YYYYMMDD" to open the specified day without any timezone configuration
if you look at the 'impl_handleURI' function in 'calendar-component.c', the standard function 'time_from_isodate' is used to parse 'startdate' and 'enddate' values. the 'time_from_isodate' documentation states the string must be a Date/time value in ISO 8601 UTC format. in other words, the date string must include the time and be in UTC, so this is not a bug but correct behavior. the format is also specified in bug #162305.
Right, evolution expects the time in UTC. Being it a full time or a date only doesn't matter to it. But it's not that hard to change, thus let's have it. Created commit 89be8b7 in evo master (3.17.3+)