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 503029 - g_time_val_from_iso8601 parse non-ISO8601 dates
g_time_val_from_iso8601 parse non-ISO8601 dates
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2007-12-11 11:00 UTC by Bastien Nocera
Modified: 2007-12-19 17:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
glib-ignore-non-iso8601-dates.patch (642 bytes, patch)
2007-12-11 16:43 UTC, Bastien Nocera
none Details | Review

Description Bastien Nocera 2007-12-11 11:00:52 UTC
Parsing this date:
Thu, 06 Apr 2006 09:00:00 PDT
Gives back an ISO8601 date:
-1-11-30T00:00:00Z
Comment 1 Bastien Nocera 2007-12-11 11:18:28 UTC
This string is used in this Podcast:
http://www.symantec.com/content/en/us/about/rss/ent/ent.xml
and parsed using totem-pl-parser.

It should be enough to check whether the first bits of string passed are numerical or not, rather than blindly pushing them through strtoul.
Comment 2 Bastien Nocera 2007-12-11 16:43:45 UTC
Created attachment 100771 [details] [review]
glib-ignore-non-iso8601-dates.patch

Patch tested with the mentioned testcase.
Comment 3 Matthias Clasen 2007-12-13 02:39:20 UTC
From looking at the "Years" section of http://en.wikipedia.org/wiki/ISO_8601
it appears that -50000-01-01 is a valid way to refer to January 1, 50000BC
Comment 4 Bastien Nocera 2007-12-13 10:51:22 UTC
(In reply to comment #3)
> From looking at the "Years" section of http://en.wikipedia.org/wiki/ISO_8601
> it appears that -50000-01-01 is a valid way to refer to January 1, 50000BC

I guess we can easily check whether the first digit is a '-'.

+  if (!g_ascii_isdigit (*iso_date) || *iso_date != '-')

Would that do?
Comment 5 Matthias Clasen 2007-12-13 13:43:48 UTC
According to the article I cited, it can also be a +.
Anyway, how does that help you with your example of -1-11-30T00:00:00Z ?
Comment 6 Bastien Nocera 2007-12-13 14:16:35 UTC
(In reply to comment #5)
> According to the article I cited, it can also be a +.

+  if (!g_ascii_isdigit (*iso_date) || *iso_date != '-' || *iso_date != '+')

> Anyway, how does that help you with your example of -1-11-30T00:00:00Z ?

No, the bug is that g_time_val_from_iso8601 parses "Thu, 06 Apr 2006 09:00:00 PDT" as an ISO 8601.

Comment 7 Matthias Clasen 2007-12-13 14:30:54 UTC
Ah, ok then. Go ahead, with that change.
Comment 8 Bastien Nocera 2007-12-13 14:47:52 UTC
Fixed in trunk and 2.14. Thanks.

2007-12-13  Bastien Nocera  <hadess@hadess.net>

        * glib/gtimer.c: (g_time_val_from_iso8601):
        Don't try to parse dates that start with anything but a
        digit, a plus or a minus sign, as those can't be valid
        ISO8601 dates (Closes: #503029)
Comment 9 Emmanuele Bassi (:ebassi) 2007-12-19 17:24:03 UTC
the applied patch is completely wrong: the icondition checked will always fail, and it's also missing a pointer dereference (which produced a warning).

this fixes the regression spotted by the test suite and fixes the bug as well.

-  if (!g_ascii_isdigit (*iso_date) || iso_date != '-' || *iso_date != '+')
+
+  if (!g_ascii_isdigit (*iso_date) && *iso_date != '-' && *iso_date != '+')

I can apply it and add a check on the test suite as well.
Comment 10 Emmanuele Bassi (:ebassi) 2007-12-19 17:32:48 UTC
committed to trunk, should go in glib-2-14 as well.

2007-12-19  Emmanuele Bassi  <ebassi@gnome.org>

        * glib/gtimer.c (g_time_val_from_iso8601): Fix the date validation
        check. (#503029)

        * tests/testglib.c (various_string_tests): Add an invalid date
        for testing the above fix.
Comment 11 Emmanuele Bassi (:ebassi) 2007-12-19 17:42:04 UTC
committed to glib-2-14 branch as well.