GNOME Bugzilla – Bug 732809
evolution-3.12.3: cannot edit google contact due to invalid format of timestamp
Last modified: 2014-09-26 09:46:43 UTC
As reported downstream at: https://bugs.gentoo.org/show_bug.cgi?id=516494 - From the start side of evolution I go to "Contact". - I select gmail contacts. - I make a right mouse click at an entry and select "Open contact" - I go telephone and select "Mobile phone" - I enter the number. - I press the save button in the contact editor window: And get an new window with the error message. URI solicitada o cabecera no válida, o parámetro no estándar no soportado: <?xml version="1.0" encoding="UTF-8"?> <errors xmlns="http://schemas.google.com/g/2005"> <error> <domain>GData</domain> <code>invalid</code> <internalReason>Invalid value for: Invalid format: "2010-06-03T10:01:08Z" is malformed at "Z"</internalReason> </error> </errors>
Thanks for a bug report. What is your libgdata version, please? If I use more latest (0.15.1), then I do not see the error. As I think it's an issue in libgdata, I'm moving this there. Feel free to reassign to evolution-data-server, if I'm wrong.
I have 0.14.3... 0.15.x is "unstable" no? :/
Maybe related with: https://git.gnome.org/browse/libgdata/commit/?id=76ea0e7dc549e4abfbab6caca87fa834245a3b88 not sure if would be safe to backport to 0.14.x series
(In reply to comment #2) > I have 0.14.3... 0.15.x is "unstable" no? :/ Correct. (In reply to comment #3) > Maybe related with: > https://git.gnome.org/browse/libgdata/commit/?id=76ea0e7dc549e4abfbab6caca87fa834245a3b88 > > not sure if would be safe to backport to 0.14.x series It’s unrelated. Can you please provide a debug log (LIBGDATA_DEBUG=3 G_MESSAGES_DEBUG=all, redact any personal details) coupled with an error message? From the logs in the Gentoo bug report, I can’t actually work out which of three dates in the XML is causing the problem, and all of them apparently allow associated times according to Google’s protocol documentation. You’re right in that it’s probably a change at Google’s end rather than in libgdata.
Possibly irrelevant, but have you considered using SoupDate internally in libgdata? libsoup seems to have a much more sophisticated date string parser than GLib and can auto-detect a variety of date formats. https://developer.gnome.org/libsoup/stable/libsoup-2.4-Soup-Miscellaneous-Utilities.html#soup-date-new-from-string That of course assumes Google is compliant with one of these formats...
(In reply to comment #5) > Possibly irrelevant, but have you considered using SoupDate internally in > libgdata? libsoup seems to have a much more sophisticated date string parser > than GLib and can auto-detect a variety of date formats. > > https://developer.gnome.org/libsoup/stable/libsoup-2.4-Soup-Miscellaneous-Utilities.html#soup-date-new-from-string > > That of course assumes Google is compliant with one of these formats... I hadn’t considered it, but it would be irrelevant here, as I suspect the problem is the format libgdata is _outputting_ rather than parsing. It looks like Google might have arbitrarily switched from being conformant with one of those formats to merely documenting that they are, and actually not being. But I should curb my cynicism and wait for a full debug log to diagnose this properly.
(In reply to comment #4) > (In reply to comment #2) > > I have 0.14.3... 0.15.x is "unstable" no? :/ > > Correct. > > (In reply to comment #3) > > Maybe related with: > > https://git.gnome.org/browse/libgdata/commit/?id=76ea0e7dc549e4abfbab6caca87fa834245a3b88 > > > > not sure if would be safe to backport to 0.14.x series > > It’s unrelated. > > Can you please provide a debug log (LIBGDATA_DEBUG=3 G_MESSAGES_DEBUG=all, > redact any personal details) coupled with an error message? From the logs in > the Gentoo bug report, I can’t actually work out which of three dates in the > XML is causing the problem, and all of them apparently allow associated times > according to Google’s protocol documentation. You’re right in that it’s > probably a change at Google’s end rather than in libgdata. I don't get anything related, only some gcr DEBUG messages before trying to edit the contact and, when I edit the contact and it fails, I see no new message :/
Did you run evolution-addressbook-factory with those debug flags? It's where the connection to the Google server is done. $ export LIBGDATA_DEBUG=3 $ export G_MESSAGES_DEBUG=all $ /usr/libexec/evolution-addressbook-factory -w &>log.txt
Ah, ok, I run it with full evolution sorry
Created attachment 280213 [details] log.txt
Since some days I have same problem. libgdata.x86_64 0.14.1-1.fc20 evolution.x86_64 3.10.4-2.fc20 I was discussing the issue in at "ubuntuusers.de", where I found other users reporting it: http://forum.ubuntuusers.de/topic/evolution-kann-google-kontakte-nicht-aendern/ If can be anyhow helpful here, please tell me how.
(In reply to comment #10) > Created an attachment (id=280213) [details] > log.txt Thanks, that’s very helpful. It looks like this is a change on Google’s servers. I can’t see any way in which libgdata is not conforming to their specification here, so am reluctant to make any changes in libgdata. I’ve filed a bug with Google: https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3595 Please star that issue if you’re interested in it, but don’t clutter it with ‘me too’ comments. Hopefully it’s a big enough issue that it will be fixed on their end in the next few days. If not, I will have to see if there are any work arounds I can implement in libgdata. I’ll close this as NOTGNOME for now, but may reopen it if a workaround is needed.
Milan, Matthew: I’m going to be away for a few weeks and haven’t managed to come up with a fix for this so far. If anything useful comes to light, please do push a fix to the libgdata repository. :-)
*** Bug 733986 has been marked as a duplicate of this bug. ***
Going on a longshot based on a few links I found online, since I can’t reproduce the bug. It seems date formats ending in ‘.000001+00:00’ apparently work, which libgdata was already using for JSON APIs, but not XML APIs (since we, reasonably, expected microsecond-less RFC3339 dates to work). Hopefully these two patches will fix the problem.
commit 45459fba6f808340d7b509c51fadf32438e5c58a Author: Philip Withnall <philip@tecnocode.co.uk> Date: Sat Aug 9 21:14:47 2014 +0100 core: Remove outdated gdata_parser_int64_to_json_iso8601() gdata_parser_int64_to_iso8601() now does exactly the same. https://bugzilla.gnome.org/show_bug.cgi?id=732809 gdata/gdata-entry.c | 2 +- gdata/gdata-parser.c | 6 ------ gdata/gdata-parser.h | 1 - gdata/services/freebase/gdata-freebase-search-query.c | 2 +- gdata/services/tasks/gdata-tasks-task.c | 4 ++-- 5 files changed, 4 insertions(+), 11 deletions(-) commit 18c16bfc9e517d44bf84449e58cc5b10bde07f09 Author: Philip Withnall <philip@tecnocode.co.uk> Date: Sat Aug 9 21:10:03 2014 +0100 core: Tweak generated ISO8601 dates to appease Google’s parsers Even though the protocol documentation claims to accept RFC3339 dates, the servers have recently started rejecting dates formatted as ‘2014-08-09T21:10:05Z’ which don’t include microseconds and specify the timezone non-numerically. Since the issue hasn’t been resolved at Google’s end, we need to hack the date formats generated by libgdata to appease the servers, completely undermining the point of having a defined protocol and RFC to base the code on. Sigh. Change gdata_parser_int64_to_iso8601() to produce dates in the format ‘YYYY-MM-DDTHH:MM:SS.000001+00:00’. This was previously used by the JSON output generator, so perhaps the server breakage was introduced when Google started rolling out the JSON APIs. https://bugzilla.gnome.org/show_bug.cgi?id=732809 gdata/gdata-parser.c | 29 +++++++++++++++++------------ gdata/tests/calendar.c | 20 ++++++++++---------- gdata/tests/general.c | 32 ++++++++++++++++---------------- gdata/tests/youtube.c | 16 ++++++++-------- 4 files changed, 51 insertions(+), 46 deletions(-)
If someone could test with those two patches applied to their copy of libgdata, and verify that they fix the issue, that would be great. Then I could make a 0.15.3 release containing the fix.
*** Bug 734279 has been marked as a duplicate of this bug. ***
*** Bug 734231 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > If someone could test with those two patches applied to their copy of libgdata, > and verify that they fix the issue, that would be great. Then I could make a > 0.15.3 release containing the fix. Cannot the fixes be backported to 0.14? (to keep "stable" libgdata for gnome 3.12 setups... or is 0.16 safe for 3.12 too?) Thanks
(In reply to comment #20) > Cannot the fixes be backported to 0.14? (to keep "stable" libgdata for gnome > 3.12 setups... or is 0.16 safe for 3.12 too?) 0.16 should be safe for 3.12, as per libgdata’s forwards-ABI-compatibility policy. :-)
(In reply to comment #21) > (In reply to comment #20) > > Cannot the fixes be backported to 0.14? (to keep "stable" libgdata for gnome > > 3.12 setups... or is 0.16 safe for 3.12 too?) > > 0.16 should be safe for 3.12, as per libgdata’s forwards-ABI-compatibility > policy. :-) Proof: http://upstream-tracker.org/versions/libgdata.html :-)
Thanks for the info (uh, didn't know that tool for checking the the compat :O)