Re: RFC: On date and time

[Iago Toral <itoral igalia com>]

On Thu, 02 Jun 2011 17:32:00 +0200, Guillaume Emont 
<guijemont igalia com> wrote:
> On 02/06/2011 16:02, Iago Toral wrote:
> > Hi,
> > On Thu, 02 Jun 2011 14:43:39 +0200, Guillaume Emont
> > <guijemont igalia com> wrote:
> > (...)
> > > 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.
> >
> > Sounds reasonable.
> >
> > One question on how this should work, since _DATE and _RELEASE_YEAR 
> > are
> > very related.
> > Are plugin developers going to do:
> >
> > grl_media_set_creation_date (date)
> > grl_media_set_release_year (YEAR(date))
> >
> > or are we going to provide something like this instead?:
> >
> > plugin developer only does:
> > grl_media_set_creation_date (date);
> >
> > and then grl_media_get_release_year just gets the year from the 
> > release
> > date.
> Good question. I initially thought of them as separated. The pros and
> cons I can see about joining them are the following:
> Pros:
>  - release year would be more systematically set, which could make it
> more useful for filtering.
>  - less code to set the year
> Cons:
>  - release year and creation date might not always have an 
> overlapping
> meaning. Imagine a music album recorded in December 2010, and 
> released
> (after post-production) two months later. Worst: plugins such as
> filesystem might be tempted to put the file creation time in there,
> which would have nothing to do with the release year.
>  - setting two keys when only asking to set one might be a bit 
> suprising
> to some developers, and code that looks good like the following would
> become wrong:
>  grl_media_set_release_year (get_year_from_mp3_tag (filepath));
>  grl_media_set_creation_date (g_file_info_get_attribute_uint64 (info,
>                                       
> G_FILE_ATTRIBUTE_TIME_CREATED));
>
> I have a feeling that the cons outweigh the pros here, but I might be
> forgetting something.

Yeah, you are probably right, let's go with separated keys then.

Iago