GNOME Bugzilla – Bug 581844
System.DateTime implementation produces timestamps incompatible with Tomboy
Last modified: 2009-06-15 19:01:24 UTC
When a note is opened in GNote, the timestamp is updated. Unfortunately, the format of the timestamp with GNote is like this: 2009-04-20T04:29:23.219734Z Tomboy's timestamps are formatted like this: 2008-11-04T15:35:42.2542360-05:00 Note that GNote is writing timestamps in Zulu and appending a Z to denote that. Tomboy uses the "-05:00" format of offsetting from UTC. The effect is that if you open a note in GNote and then that note makes its way to ~/.tomboy (copying, synchronizing, symlinking .tomboy->.gnote, whatever), Tomboy will do naught but crash on startup.
If tomboy crash then Gnote is not the one with the bug. Copying the notes back to Tomboy is not supported either. iso8601 conversion is done by glib. This bug is likely WONTFIX candidate.
Do you intend to be compatible with Tomboy or not? I consider interoperability and standard formats a Good Thing. Yes, these are both iso8601, but why use the UTC one when the application it's meant to emulate uses localtime? That doesn't seem like very complete emulation.
Tomboy crashing is a Tomboy bug; I will fix that, because I do care about users being able to do whatever they want with their notes. I also think that we should cooperate on note XML format...I had assumed Gnote was creating identical notes as Tomboy, but if there is a reason that cannot be, it seems like it's in everybody's best interest to try to have some compatibility.
The date looked like it it was ISO 8601 so I assumed it was and let glib handle it for me. Yes there is a difference between GMT and local time, but as long as this time offset is taken into account (and it is), it shouldn't even be relevant.
In git master, Tomboy now allows more date formats and is overall more defensive in its note XML parsing.
marking as fixed. Thanks Sandy.
Hey Hubert, I notice the status on this changed to UNCONFIRMED. Need any more work done on the Tomboy side?
no no. product = gnote it is for me :-) thanks.
for the record, it is an issue in glib or libc. If the tv_usec value of GTimeVal is 0, g_time_val_to_iso8601() (by way of the libc) just skip the usec value, that Tomboy is expecting. This is definetely wrong one way or the other, and sandy prevented the crash from malformed input, I have to fix this side too.
This time it is really fixed. But, Mackenzie, instead of going nuts by claiming *everywhere* that Gnote is a vendor lock-in, provide the data set to be examined by the developer. Yes it was a bug, but it took me some digging to figure out what was happening, having provided with the data set, it would have been easier. This will be in 0.5.0 that I will release Wednesday. Thanks to Sandy for the help.
I gave you the exact strings that were causing the incompatibility. Are two whole notes really necessary when they match in every other way and manually editing any note to have a timestamp like the other does it? How did you want me to interpret "Copying the notes back to Tomboy is not supported either...WONTFIX," if not creating lock-in, preventing users who so much as try it out for 5 minutes from not being able to go back?
Except that said data do work in both situation. The timezone was not the problem. But on the internet it is easier to point the problem wrongly than finding the proper solution. And yes my mistake I closed the bug too fast after the ultra quick-fix from Sandy.