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 618125 - Due date time zone not set when using "Click to add task"
Due date time zone not set when using "Click to add task"
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Tasks
2.32.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
: 620442 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-05-08 17:13 UTC by Pacho Ramos
Modified: 2017-09-01 08:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
1.png (75.68 KB, image/png)
2010-05-08 17:13 UTC, Pacho Ramos
Details

Description Pacho Ramos 2010-05-08 17:13:21 UTC
Created attachment 160599 [details]
1.png

This was reported downstream to:
http://bugs.gentoo.org/show_bug.cgi?id=318623

and reproduced here. You can see attached screenshot to view current situation. For testing this problem, you need to have "Due date" column added and, then:
1. Click on "Click to add a task" line, adding a task called "test0"
2. Click on "Due date" box for that task to set due date and time -> The task now changes to the normal color of your task list (not the same *blue* used when adding task using the second method explained below)
3. Wait until the time of the task is gone. -> The task don't change the color
to red as it should.

Now, try to add a second task using "New" button:
1. Click on "New" -> You get a new dialog window.
2. Give a name to the task ("test1"), an end date and time. Click save. -> The
new task test1 is shown in the list in *blue*.
3. Wait until the time of test1 is gone -> The task changes the color to red as
it should.

I am using evolution-2.28.3.1

Thanks
Comment 1 Matthew Barnes 2010-06-03 12:07:18 UTC
*** Bug 620442 has been marked as a duplicate of this bug. ***
Comment 2 Ruchir Brahmbhatt 2010-07-15 07:22:13 UTC
It is reproducible in 2.31.x.
Comment 3 Ruchir Brahmbhatt 2010-09-30 12:04:43 UTC
It's in 2.23.0 final also.
Comment 4 Milan Crha 2017-09-01 08:06:03 UTC
Thanks for a bug report. One problem was that the time zone was not set on the Due date, which confused the code. I also noticed another issue, when the date had been changed inline, the code wanted to preserve the current time zone, which broke the code due to setting the same string into the libical structure, which doesn't behave properly and causes use-after-free. Both things are fixed now.

Created commit a00f6b1 in evo master (3.25.92+)