glib::Date::new_from_iso8601 feature?

Platform
1

I don’t want to parse date+time in my app, but glib::Date does not implement useful new_from_iso8601 method unlike glib::DateTime:

Is any plans to make this API in future?

Of course, I can create the date object with Date::new_dmy, but can’t format it back to string using method like :

So currently glib::Date not useful for me, even I want to replace it with glib::DateTime

2

No.

GDate is a very simple API, with a very limited set of use cases.

Anything that deals with date, time, and time zones should be using GDateTime.

1 Like
3

Well, thanks for reply

Even currently I’m using code like:

DateTime::from_iso8601(&format!("{date}T00:00:00"), timezone)

because it could not be parsed from YYYY-MM-DD but okay

4

To expand a bit on that:

  • GDate is an old API and doesn’t conform to any new conventions for how to write APIs. In particular, it’s stack allocated, which means we can’t easily expand it to store additional data (which might be needed for adding new methods).
  • In anything other than very simple cases, dates can only be interpreted with respect to a timezone — it’s never the same date across the entire world, so your interpretation of a particular date string has to depend on timezone and time.

On the flipside, GDateTime doesn’t provide particularly handy APIs for the case where you only care about the date it represents. We could probably do better there, if someone were to work on improving that use case.

1 Like
5

In theory, YYYY-MM-DD without the time (and time zone) is still considered a valid ISO 8601 date; the main issue is that, of course, the whole API is a misnomer—one for which I can mostly take the blame, having written the original g_time_val_from_iso8601() and g_time_val_to_iso8601() that have been the basis of the equivalent API in GDateTime. The GLib API has always really been an RFC 3339 parser, and that format requires date, time, and time zone. If we really wanted to parse timing data formatted using ISO 8601, we’d need a vastly more complex parser—one that includes, among other things:

  • week dates
  • ordinal dates
  • durations
  • time intervals (repeating and non-repeating)

Coupled with an incredibly extensive test suite.

1 Like
6

I think there would be scope for a middle ground: a parser which says it accepts a (specifically defined) subset of ISO 8601, which includes YYYY-MM-DD and RFC 3339, but which explicitly doesn’t accept week dates and all that esoteric stuff. The vast majority of ISO 8601 dates in the wild follow a couple of patterns.

1 Like
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.