RFC: On date and time

[Guillaume Emont <guijemont igalia com>]

Hi all,

In the context of the implementation of caps, options, key filtering and
key range filtering that I am currently doing, I found some limitations
in the current way we handle dates, and I am thinking of making these
things evolve (in 0.2.x).

Two metadata keys hold dates:
 - GRL_METADATA_KEY_DATE, "Publishing or recording date"
 - GRL_METADATA_KEY_CREATION_DATE, "Creation date"
In both cases, their type is loosely defined as strings that contain an
ISO-8601 date, though it is not clear what part of ISO-8601 is accepted,
and some code seems to use g_time_val_from_iso8601() or functions like
that, which only accept a subset of ISO-8601.

The way this is handled have several limitations:
1/ The date strings are not parsed before they are used, meaning that
invalid dates might trigger run time errors in code segments far away
from the code providing the erroneous string (and potentially executing
much later). Invalid dates should not be accepted.
2/ Some dates that we would need to handle have little precision (think
of the release year of a music album or a film) and cannot be reliably
handled by this scheme, since functions like g_time_val_from_iso8601()
only accept a full date and time string. Most importantly, mixing
date/times of varying precisions makes comparisons much trickier to
define. If a user requests all medias dated between "1998-07-15" and
"2001-01-01", should a media dated "2001" be included? And what about a
request for medias in the range (2001-12-31, 2003-09-12)? Should two
clearly non overlapping ranges contain media in common?

The solution I propose to solve these issues, and will start
implementing right now unless some people come up with better proposals,
is the following:

 - Store the _DATE and _CREATION_DATE keys as GDateTime. Since GDateTime
is generally not available/not working in language bindings, some
wrappers will be provided to be able to set them with strings (like it
is done currently, except that format checking will be done immediately)
 - Add a GRL_METADATA_KEY_RELEASE_YEAR key that would contain an
integer. Some other "imprecise" date keys might be needed (please
suggest), but this is the only one I could think of for now. That would
cover things like the release year of a music album/track or the release
year of a film.

Constructive comments welcome!

Thanks,

Guij