Re: RFC: On date and time



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.

Guij


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]