Created attachment 319549 [details] [review]
Parse date-only ISO 8601 representations

A date in the format of YYYY-MM-DD, or YYYYMMDD, is a perfectly valid
ISO 8601 representation, and we should be able to parse it.

Just on a sidenote, in GStreamer we have GstDateTime which is basically GDateTime just with the additional feature that it supports 'partial' information, i.e. just a year, year/month, or just a date but no time, and the user can know which fields are available or not, and serialisation/deserialisation is consistent then and doesn't add information that's not in the original data.

(In reply to Emmanuele Bassi (:ebassi) from comment #1)
> A date in the format of YYYY-MM-DD, or YYYYMMDD, is a perfectly valid
> ISO 8601 representation, and we should be able to parse it.

Yes, but it's NOT a representation of the same thing as "YYYY-MM-DDT00:00:00". "YYYY-MM-DD" means "an unspecified time on YYYY-MM-DD", not "midnight on YYYY-MM-DD". (And, as Tim-Philipp notes, it should deserialize back to "YYYY-MM-DD", not to "YYYY-MM-DDT00:00:00".)

(Does this matter for GDateTime's purposes? I dunno...)

(In reply to Dan Winship from comment #3)
> (In reply to Emmanuele Bassi (:ebassi) from comment #1)
> > A date in the format of YYYY-MM-DD, or YYYYMMDD, is a perfectly valid
> > ISO 8601 representation, and we should be able to parse it.
> 
> Yes, but it's NOT a representation of the same thing as
> "YYYY-MM-DDT00:00:00". "YYYY-MM-DD" means "an unspecified time on
> YYYY-MM-DD", not "midnight on YYYY-MM-DD".

That's an interpretation that is entirely context-dependent.

Since we're transforming a date representation into a timestamp, it's perfectly within the letter of the ISO 8601 spec to consider midnight as the result of the transformation.

If I do:

    date -d '2006-07-07' +%s -u

I get back:

    1152230400

> (And, as Tim-Philipp notes, it
> should deserialize back to "YYYY-MM-DD", not to "YYYY-MM-DDT00:00:00".)

Again, we're transforming a timestamp that is based on seconds. It's perfectly fine to turn it into a full date + time representation — i.e. it does not need to round trip precisely.

For sake of consistency, we could ensure that the g_time_val_to_iso8601() function returned just the date if the time matches 00:00:00, which is consistent with what `date -d '@1152230400' -I` does.

> (Does this matter for GDateTime's purposes? I dunno...)

This is not what the patch is meant to be used for.

I agree that roundtripping is not really a requirement - g_time_val_to_iso8601 is somewhat arbitrary in picking one of the many possible iso8601 formats anyway.

But I do think that the patch is missing an update to the documentation that currently says:

@iso_date must include year, month, day, hours, minutes, and seconds.

Created attachment 320740 [details] [review]
Parse date-only ISO 8601 representations

A date in the format of YYYY-MM-DD, or YYYYMMDD, is a perfectly valid
ISO 8601 representation, and we should be able to parse it.

Patch updated, with the new documentation.

Created attachment 320741 [details] [review]
Parse date-only ISO 8601 representations

A date in the format of YYYY-MM-DD, or YYYYMMDD, is a perfectly valid
ISO 8601 representation, and we should be able to parse it.

Created attachment 320742 [details] [review]
Serialize midnight to an ISO 8601 date fragment

We can omit the time fragment, to allow round-tripping between
g_time_val_from_iso8601() and g_time_val_to_iso8601().

Comment on attachment 320742 [details] [review]
Serialize midnight to an ISO 8601 date fragment

We can say that *we* want to interpret no time as being the same as midnight, but we can't assume that all downstream consumers of g_time_val_to_iso8601 will do the same. So I'd say we don't want this patch even if we do commit the other one (which I'm neutral on now)

(In reply to Dan Winship from comment #10)
> Comment on attachment 320742 [details] [review] [review]
> Serialize midnight to an ISO 8601 date fragment
> 
> We can say that *we* want to interpret no time as being the same as
> midnight, but we can't assume that all downstream consumers of
> g_time_val_to_iso8601 will do the same. So I'd say we don't want this patch
> even if we do commit the other one (which I'm neutral on now)

Yep, I agree on this; I just wanted to attach it here so that we can have a more formal rejection.

Comment on attachment 320742 [details] [review]
Serialize midnight to an ISO 8601 date fragment

ok then

See bug 753459 for a comprehensive ISO 8601 parser for GDateTime.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1125.