Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#998737: gnote: Timestamp is not in ISO 8601 format

10 views
Skip to first unread message

Zoltan Adasz

unread,
Nov 7, 2021, 7:10:04 AM11/7/21
to
Package: gnote
Version: 3.38.0-1
Severity: important

Dear Maintainer,

I observed synchronization errors with Tomdroid (Android app using Tomboy's
note format) with notes changed by the latest (Debian Bullseye) version of
GNote. I was able to track the this particular problem down to a tag in the
note file: "last-change-date" ("last-metadata-change-date" is also affected).
AFAIK, these should be in ISO 8601 format, which requires zero padded hour /
minute / second values. However I see timestamps not following this rule. For
example:

<last-change-date>2021-11-07T11:10:3.396594Z</last-change-date>

How to reproduce: change a note in the first 9 seconds of a minute.

I don't know, if this causes problems with any other application using the note
format. I'm also not sure, if this problem directly relates to GNote or a
library used internally to handle timestamp "serialization" / XML writing.


-- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnote depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2
ii libatkmm-1.6-1v5 2.28.0-3
ii libc6 2.31-13+deb11u2
ii libgcc-s1 10.2.1-6
ii libglib2.0-0 2.66.8-1
ii libglibmm-2.4-1v5 2.64.2-2
ii libgspell-1-2 1.8.4-1
ii libgtk-3-0 3.24.24-4
ii libgtkmm-3.0-1v5 3.24.2-2
ii libpango-1.0-0 1.46.2-3
ii libpangomm-1.4-1v5 2.42.1-1
ii libsecret-1-0 0.20.4-2
ii libsigc++-2.0-0v5 2.10.4-2
ii libstdc++6 10.2.1-6
ii libuuid1 2.36.1-8
ii libxml2 2.9.10+dfsg-6.7
ii libxslt1.1 1.1.34-4

gnote recommends no packages.

gnote suggests no packages.

ADA

unread,
Dec 9, 2021, 8:20:03 AM12/9/21
to

Hi,

I've found the problem, why the timestamp, which should be in ISO 8601
format gets "corrupted". This problem exists in all current GNote
packages, including the original source (GitLab GNote master).

The problem is in datetime.cpp, function date_time_to_iso8601.

Link on GitLab:
https://gitlab.gnome.org/GNOME/gnote/-/blob/master/src/sharp/datetime.cpp

Bug was introduced with this commit:

https://gitlab.gnome.org/GNOME/gnote/-/commit/b30cd91826d2ee3b953b2485683ba8011be0434d


Short C program to demonstrate the problem, let's reuse portion of
that function and dump the current timestamp to the console:


#include <stdio.h>
#include <string.h>

int main(void) {
char buffer[36] = {0};

sprintf(buffer, "%d-%02d-%02dT%02d:%02d:%02.6lfZ", 2021, 12, 9, 13,
51, 3.01918745645);
printf("%s\n", buffer);
}


This outputs:
2021-12-09T13:51:3.019187Z

There's no zero padding in the seconds part, due to how %02.6 is
interpreted for floats. This is a possible fix:


#include <stdio.h>
#include <string.h>

int main(void) {
char buffer[36] = {0};

sprintf(buffer, "%d-%02d-%02dT%02d:%02d:%09.6lfZ", 2021, 12, 9, 13,
51, 3.01918745645);
printf("%s\n", buffer);
}


This outputs:
2021-12-09T13:51:03.019187Z


This is what we want to see. Just change %02.6lf to %09.6lf in the
sprintf call.

IMHO, this should be also communicated upstream. Thanks!

Best regards,
Zoltan Adasz

ADA

unread,
Dec 19, 2021, 5:40:03 AM12/19/21
to

Hi,

I've created an issue for this problem on GNote's Gitlab, with my
proposed solution:

https://gitlab.gnome.org/GNOME/gnote/-/issues/115

Solution was committed also adding a test for this scenario:

https://gitlab.gnome.org/GNOME/gnote/-/commit/8ac82d0d6bbfd77f8675c1c85de9076274a69c81

So the problem is fixed and available on GNote's master.


Best regards,
Zoltan Adasz
0 new messages