Clicking on date in calendar applet open previous date in Evolution

[joehill]

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).

[Sebastien Bacher (seb128)]

Thanks for your bug. What version of Ubuntu do you use? What locale and timezone? That works fine for me. Does "evolution calendar:///?startdate=$(date +"%Y%m%dT%H%M%SZ")" open on the current day for you?

[joehill (joseph-hill)]

I'm using an updated Dapper. I've had this problem ever since I upgraded from Breezy. (Several minor things broke when I upgraded.) Yes, the command you provided does open up on the right day.

[Zach Tibbitts (zrtibbitts)]

I have the exact same problem, using dapper, fresh install.
yes, that command opens the current day

[Sebastien Bacher (seb128)]

what locale do you use?

[joehill (joseph-hill)]

Is the locale the same as $LANG? If so, it's en_US.UTF-8. The time zone is America/New York (Eastern).

[Sebastien Bacher (seb128)]

Confirmed, it depends of the timezone configured for evolution. Are you sure you don't have the issue with "evolution calendar:///?startdate=$(date +"%Y%m%dT%H%M%SZ")"? It opens the previous day too on my dapper installation. I've forwarded the issue upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=341348

[joehill (joseph-hill)]

Strangely enough, that command still opens up the correct day, whereas clicking on the date still opens up the previous day.

[Kyle Andrews (kyle-c-andrews)]

Both evolution calendar:///?startdate=$(date +"%Y%m%dT%H%M%SZ") and the calendar give me the previous date.

[Sean (sean-compusmith)]

I can confirm and I'm also using en_US.UTF-8 and my time zone is America/New_York (Eastern). When I run:

evolution calendar:///?startdate=$(date +"%Y%m%dT%H%M%SZ

It opens the previous day in Evolution. Same goes for opening Evolution from the calendar applet in the Gnome panel -- previous day.

[Tomi Urankar (tomi0)]

4M its even worse. Since I removed Evolution when double clicking on a date the CLOCK applet crashes.

[Alvin Thompson (alvint-deactivatedaccount)]

let's eliminate some of the variables, here. explicitly specifying the date with the command:

evolution calendar:///?startdate=20060608T114022

starts evolution with the correct date (8 june 2006). however, omitting the time portion with the command:

evolution calendar:///?startdate=20060608

starts evolution with the incorrect date (*7* june 2006). a safe workaround could be having the calendar applet include the time on its command line for starting evolution.

[Alvin Thompson (alvint-deactivatedaccount)]

this is probably not a bug, as evolution is probably assuming 00:00 zulu for the time. this gets converted to the previous day for those of us in a "minus" time zone. the command line for gnome-panel needs to specify the correct time zone. i've opened bug #46805.

[Alvin Thompson (alvint-deactivatedaccount)]

yes, that's exactly what's happening. i'm in Eastern Standard Time, USA, which is currently GMT minus 4 hours. the command:

evolution calendar:///?startdate=20060608T035959

opens evolution to the previous day, while the command:

evolution calendar:///?startdate=20060608T040000

opens evolution to the correct day.

[Alvin Thompson (alvint-deactivatedaccount)]

conclusion: this is not a valid bug.

[Sebastien Bacher (seb128)]

I don't agree with the fact that not a bug, "startdate=a_date" should open the date specified without hour specification, that seems logicial no? Implementation details are not a justification for a bugged behaviour

[Alvin Thompson (alvint-deactivatedaccount)]

you're missing the point. the command DOES work properly, but since there is no time or time zone specified, evolution quite reasonably assumes 00:00 zulu. for those of us in EDT, this get translated to 8PM of the previous day.

[joehill (joseph-hill)]

I agree with Sebastien. I don't care about the logic of what's happening behind the scenes (I'm not a hacker, I'm just a simple user) but with the fact that the interface doesn't do what it should do. Clicking on/typing a given date should open that date. Simple, right? How can you say that opening a date other than the one specified is not a bug? Are you saying that it's normal that everyone living west of London should have to click on the wrong date to open the right one? Please explain, I'm confused.

[Alvin Thompson (alvint-deactivatedaccount)]

i know it sounds like i'm arguing semantics, but in this case semantics are important. the reason that i want to make the distinction clear is because this bug is mirrored upstream, and the Evolution maintainers need to know that there's actually no problem with their code. in fact, they should NOT change how the command works between major releases (if at all) because doing so would break the existing valid contract.

to further explain, evolution IS opening the the date that was specified. the problem is that gnome-panel is telling evolution to open the wrong date. to better understand this, you need to realize that evolution is not opening a DAY, but rather a POINT IN TIME. the point in time 8 June 00:00 GMT is actually 7 June 20:00 for those in EDT.

[Sebastien Bacher (seb128)]

Alvin, I don't agree with you:
- startdate=YYYYMMDD is not a point of time at 00:00 GMT but a day
- evolution calendar selects a day and not an hour(?)
- the timezone should not be revelant since it's the same for all your box, the panel and evolution are working on the same timezone. If you insist on having YYYYMMDD beign a 00:00 hour it should be 00:00 current time and not GMT
- no need to unset the upstream task, upstream get nothing by it, that's just an indicator for launchpad that get updated automatically when the upstream bug change so we notice when they close bugs as fixed by example, there is nothing sent upstream automatically from launchpad

Do you have an API documentation stating that the YYYMMDD format is a 00:00 GMT hour?

[joehill (joseph-hill)]

Yes, I understand your logic. I just think it's wrong. If Evolution can't handle a plain date as a sane user (not a logician) would expect it to, then it shouldn't allow a plain date argument in the first place. To give Thursday when one asks for Friday is a bug according to any human interface standards, regardless of the time zone or semantics.

I agree that it should be changed in gnome-panel if Evolution won't fix this bug, but I'm not conceding that it's not a bug. Evolution should follow a logic that says "if argument does not include a time, then return the date only, else if time is specified, return it in user's time zone (not GMT, etc.)." Friday is not Thursday from the user's point of view, and this is a fact that Evolution (not end users) should handle.

[Alvin Thompson (alvint-deactivatedaccount)]

ughhh! i give up!

[Sebastien Bacher (seb128)]

every expressed his opinion, not a lot to say after say, let upstream decide if they think that format is a part of the API and should have some stability or if they want to fix the glitch

What hour do you think the panel should use when you click on it?

[Alvin Thompson (alvint-deactivatedaccount)]

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. the format is also specified in the upstream of bug #35167:

http://bugzilla.gnome.org/show_bug.cgi?id=162305

[Sebastien Bacher (seb128)]

any opinion on the previous comment? what hour would you use to make sure than the day will not switch if evolution is on a different timezone?

[Alvin Thompson (alvint-deactivatedaccount)]

as i mentioned in the bug i filed, a safe kludge is to always use 12 noon GMT:

evolution calendar:///?startdate=20060608T120000

since (virtually) no time zone is more than 12 hours away from GMT, this will force evolution to start on the specified date, regardless of time zone. the only people this will not work for are those few in Tonga during their DST and some parts of Kiribati. since the people of Tonga and Kiribati are primitive and their time is mostly preocupied with catching enough fish to eat, they probably won't mind if Ubuntu doesn't open the correct date in Evolution some of the time.

[Alvin Thompson (alvint-deactivatedaccount)]

evolution's calendar is supposed to scroll to the specified time, but since that has never ever actually worked, it's not an issue.

[joehill (joseph-hill)]

This is probably a workable hack for the moment (that is, it's better than leaving it the way it is).

But I still am at a loss as to why a calendar program that helps me organize my appointments in my local time and correctly reminds me of them insists on receiving GMT arguments and has no way to specify a date in my local time zone (or just a plain date without a time zone--after all, it's opening the whole day, not a time). I don't think such hacks should be necessary.

Not having a way to specify a date according to the user's time zone is a bug. Evolution is designed to help people organize their daily tasks wherever they may live. Maybe this is an upstream issue that we have to hack around here, but I at least want to recognize that it's a bug. By the way, the Tongans I've known are not primitive and are as interested in using computers and organizing their schedules as I am, so I don't buy the idea that they should be excluded because of their time zone.

[Alvin Thompson (alvint-deactivatedaccount)]

this still doesn't work for edgy and upstream (evolution) is apparently not going to fix this. since this is a very visible and annoying bug in ubuntu, and since the fix (above) is very simple and has no chance of breaking anything, i'm sure matt will allow it. i know you guys don't like deltas, but i would bet that the patch would promptly be accepted upstream (in gnome-panel). this is especially true because most other distributions maintain their own version of this fix.

[Sebastien Bacher (seb128)]

No need to get an approval from Matt and the delta is not an issue. If you want to make a patch for that you are welcome

[Sebastien Bacher (seb128)]

Marking it milestoned for edgy

[Tollef Fog Heen (tfheen)]

Trivial patch, but hey.

[Sebastien Bacher (seb128)]

Thank you for the patch Tollef, fixed with this upload:

" gnome-panel (2.16.1-0ubuntu2) edgy; urgency=low
 .
   * debian/patches/15_clock_start_evo_midday.patch:
     - patch by Tollef Fog Heen, "always use 120000Z when calling evo", fix the
       evolution calendar being opened shifted from one day sometimes depending
       on the timezone (Ubuntu: #42115)"

[Alvin Thompson (alvint-deactivatedaccount)]

outstanding!

[Sebastien Bacher (seb128)]

That workaround creates the opposite effect for some people: bug #66028 is about the next day being opened on edgy

[Alvin Thompson (alvint-deactivatedaccount)]

as discussed previously, this is a kludge and affects only people in time zones greater than UTC+12 during their daylight savings, which is far fewer than affecting everyone in a minus time zone all the time (half of the world, including the americas) as the previous code did.

also as discussed, the correct solution is to simply calculate the UTC equivalent to the current local time, and use that to open Evolution. not that hard.

[Sebastien Bacher (seb128)]

not sure of why evolution should take an UTC time rather than one matching its timezone, either way should fix it though

[Robert Di Gioia (digioiar)]

after reviewing this bug, it appears that it was fixed in Edgy.

I'm using Gutsy, and still it is opening the wrong date.

The command evolution calendar:///?startdate=$(date +"%Y%m%dT%H%M%SZ") opens Evolution with the correct date.

My locale (LANG) is en_US.UTF-8

My timezone is America/New York (Eastern).

Should I open a new bug for this or is updating this bug sufficient?

[joehill (joseph-hill)]

I can confirm that this behavior is back in Gutsy for me. I hadn't noticed because I haven't used Evolution for a while.

[Chris I-B (ve4cib)]

Confirmed here too. I was in the process of filing a new bug report for this issue.

Some extra information:
I'm running Ubuntu 7.19 x86_64 with all updates currently installed

$ uname -r
2.6.22-14-generic

$ locale
LANG=en_CA.UTF-8
LC_CTYPE="en_CA.UTF-8"
LC_NUMERIC="en_CA.UTF-8"
LC_TIME="en_CA.UTF-8"
LC_COLLATE="en_CA.UTF-8"
LC_MONETARY="en_CA.UTF-8"
LC_MESSAGES="en_CA.UTF-8"
LC_PAPER="en_CA.UTF-8"
LC_NAME="en_CA.UTF-8"
LC_ADDRESS="en_CA.UTF-8"
LC_TELEPHONE="en_CA.UTF-8"
LC_MEASUREMENT="en_CA.UTF-8"
LC_IDENTIFICATION="en_CA.UTF-8"
LC_ALL=

$ evolution --version
GNOME evolution 2.12.1

Evolution configuration:
Time Zone: America/Winnipeg (complete aside, but shouldn't that be Canada/Winnipeg?)

[Stanley Sokolow (overbyte)]

[Hardy 8.04 Alpha-2 for i386 desktop] Same faulty behaviour occurs in this iso-testing version. Relevant versions: evolution 2.21.4, Gnome panel 2.20.1, clock 2.20.1. That is, double-clicking on a date in the drop-down calendar (from the panel clock) opens the prior date (at 9:00 am) in the Evolution calendar. Clock has my correct time zone (America_Los Angeles). Evolution Preferences>General also shows my correct time zone.

[Sympy (sympathy4no1)]

I'm having this bug on Gutsy 64. Is there any workaround to it that does not involve recompiling?

[Sympy (sympathy4no1)]

By the way, my timezone is America/Sao Paulo.

[Sir Nikon (omnineko)]

I am also experiencing this issue with Gutsy. And, like Sympy, I am unsure of how to re-compile and use the hack.

Any ideas or is there an "easy" fix?

[Stanley Sokolow (overbyte)]

 I haven't been using Evolution, since I began using Google's Calendar. I tried the problem again after receiving notice of the importance change. I'm running Lucid 10.04 up-to-date. The double-click on the date in the panel's drop-down calendar opens Evolution (2.28.3) with the correct date. As far as I can see, the problem has been resolved.

[loko (arph)]

I reopen the bug because the same thing happens to me in Maverick now.

[Loïc Alejandro (loic-alejandro)]

Same problem in maverick now for me too.

[loko (arph)]

Is somebody working on this problem? It is really annoying and it seems to be a general problem of the latest linux distributions. This bug happens in fedora 14 too.

[Sebastien Bacher (seb128)]

don't reopen old closed bugs, reopen new ones rather

[Sebastien Bacher (seb128)]

"open new ones" rather, the new issues seems to be https://bugzilla.gnome.org/show_bug.cgi?id=632199