GNOME Bugzilla – Bug 372155
Calendar opens Evolution on the wrong day
Last modified: 2008-09-01 22:59:14 UTC
This bug was reported to the Debian BTS. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366970 "According to upstream's NEWS this release of GNOME Panel can open an Evolution calendar on the day clicked in the clock applet's calendar. Well, it seems that Evolution is being opened on the day before to the one picked. Go figure." The submitter gets the same result using both locale es_AR.UTF-8 and POSIX/C if it matters.
If the local timezone is a negative offset from UTC, the date and time that is passed to Evolution, which is the date and time that the selected day starts in UTC, is during the previous day in the local timezone, so Evolution opens on the previous day.
The current version of evolution can't correctly parse ISO 9601 dates, which blocks this.
Is there a bug report against (In reply to comment #2) > The current version of evolution can't correctly parse ISO 9601 dates, which > blocks this. Is there a bug filed against Evolution that reports this? The only related one I found was bug #341348, which doesn't mention this problem (though it refers to bug #162305, which is fixed but does mention this problem).
That's bug 409200 (this bug depends on bug 409200)
So if evolution does only parse UTC dates and it is unknown whether this will change soon, how about passing a correct UTC time which corresponds to the beginning of that day in my local time zone? I'll attach a patch. It got some light testing in NetBSD/pkgsrc. (The idea is similar to the Ubuntu patch, see https://bugs.launchpad.net/evolution/+bug/42115 )
Created attachment 99996 [details] [review] calculate UTC time for evolution call
Bug still happens in Gnome 2.22. It opens Evolution's Calendar one day before the date clicked.
*** Bug 499374 has been marked as a duplicate of this bug. ***
I've fixed it in a similar way. This will break when bug 409200 is resolved, though...
The fix (which is in gnome-panel-2.22.1.3) doesn't work in all situations: If the utc and local dates differ, the offset for the hour printed out will wrap over. Eg: I'm in GMT+2, and shortly after midnight utc_tm.tm_hour is 23, and local_tm.tm_hour is 1, so the time passed to evolution will be T340000.
Created attachment 109375 [details] [review] patch as in comment #6, updated for gnome-panel-2.22.1.3
*** Bug 537743 has been marked as a duplicate of this bug. ***
Created attachment 115863 [details] [review] make clock applet open correct date in evolution's calendar The analysis of Matthias Drochner in comment #10 is entirely correct. This bug should be reopened (why can't I do that?). Commit 10988 is not correct and can still (and easily) lead to opening up the calendar on a wrong date. As it turns out I've been spending some time recreating what Matthias already had done in comment #6 and comment #11. Attached is basically the same solution, just a few minor differences (a few casts, avoided bzero(), variable names), done for current trunk, tested against 2.22.2. Matthias deserves credits, as he provided the correct solution eight months ago!
Ping here? Is this really fix or should Paul's patch from comment #13 be applied? Thanks
Afaict the current date/time calculation can still overflow, as described in comment #10. So a fix is necessary. Paul's patch looks fine, and is technically identical to the one I've been testing for many months (although only in one timezone).
Add myself to cc list (somehow didn't do that before, I suppose). While I'm spamming anyway, and rather off topic: why can't third parties reopen bugs? Is there some benefit in disallowing that?
Thanks, patch committed. (In reply to comment #16) > Add myself to cc list (somehow didn't do that before, I suppose). > > While I'm spamming anyway, and rather off topic: why can't third parties reopen > bugs? Is there some benefit in disallowing that? You just need to ask for permissions on #bugs. We don't do it by default to be a bit more secure, I guess.