GNOME Bugzilla – Bug 662060
GDateTime iso8601 support
Last modified: 2017-05-02 22:40:22 UTC
As I understand it, GTimeVal is going away in the future, so it would be useful to be able to read and write iso8601 dates directly to/from a GDateTime. In case it's interesting when designing such an API, here are some other iso8601 bugs in Bugzilla: #650968, #651168, #537637.
... or Bug #650968, Bug #651168, Bug #537637 for those who like hyperlinks :-)
tl;dr: ISO 8601 is big and complicated, W3C NOTE-datetime is a strict subset of ISO 8601, RFC 3339 is a strict subset of W3C NOTE-datetime (I think). Parsing would be useful - I believe ISO 8601 is unambiguous (albeit complicated). It appears g_time_val_from_iso8601() doesn't actually allow all ISO 8601 date/times, though, only the subset from http://www.w3.org/TR/NOTE-datetime (it can't parse 2011-W42, which is this week, for instance). For output, there are so many variations of ISO 8601 that g_date_time_format() or g_strdup_printf() is probably the best way to get the exact variation you want. In practice you probably want RFC 3339, which has a limited number of options, but still has options: * number of digits of fractional seconds (or none) - g_date_time_format() cannot produce these * date, time or both (for GDateTime, we presumably want both) * represent UTC as Z or as +00:00 * optionally output the T and Z literals as t and z (but the RFC says you SHOULD always use T and Z) Unfortunately, g_date_time_format() can't do fractional seconds (because C99 strftime can't), so it can only produce ISO 8601 with 1-second precision. For your use case (Empathy? Wocky?), is what you actually want a RFC 3339 date/time? (g_time_val_to_iso8601 produces these.)
(In reply to comment #2) > It appears g_time_val_from_iso8601() doesn't actually allow all > ISO 8601 date/times, though, only the subset from > http://www.w3.org/TR/NOTE-datetime In fact it allows a *different* subset of ISO 8601 - it allows 20111018 as well as 2011-10-18, whereas NOTE-datetime does not allow omission of "-", but does allow "2011-10".
(In reply to comment #2) > Parsing would be useful - I believe ISO 8601 is unambiguous (albeit > complicated). Yes > It appears g_time_val_from_iso8601() doesn't actually allow all > ISO 8601 date/times, though, only the subset from > http://www.w3.org/TR/NOTE-datetime (it can't parse 2011-W42, which is this > week, for instance). Right, because 2011-W42 means either "all of week 42 of 2011" or "an unspecified point in time somewhere during week 42 of 2011", neither of which can really be represented as a GTimeVal. The way the function is supposed to work is that it only accepts strings that include a complete date and time (down to 1-second precision). (It also accepts strings containing just a date, and treats them as meaning midnight on that date, but that's a historical mistake, and is not documented). We could possibly add something like gboolean g_date_time_parse_iso8601_interval (const char *date_string, GDateTime **start, GDateTime **end, GError **error); for parsing "2011-W42" and the like... (Though that still wouldn't let you parse just a time.) > For output, there are so many variations of ISO 8601 that g_date_time_format() > or g_strdup_printf() is probably the best way to get the exact variation you > want. g_strdup_printf() is a little annoying with GDateTime though since you can't access the struct members directly, so you'd need a whole bunch of "g_date_time_get_year (datetime)" etc calls... We could possibly add g_date_time_to_iso8601() that takes a format string, but replacing the %-specifiers that don't make sense in ISO 8601 with alternate ones.
See bug 753459 for a solution which is probably a duplicate of this one?
I’m going to mark this bug as a duplicate of bug #753459 (even though it’s newer) since it’s the one with patches attached. Thanks, Robert. *** This bug has been marked as a duplicate of bug 753459 ***