After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 635595 - GstDateTime needs granularity API so date tags can be transcoded correctly
GstDateTime needs granularity API so date tags can be transcoded correctly
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: 0.11.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-11-23 09:56 UTC by Gautier Portet
Modified: 2012-06-16 16:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Gautier Portet 2010-11-23 09:56:20 UTC
When reading the file's tags SoundConverter gets a complete date (year/month/day) tag, without knowing which fields really were in the file.

This is a big deal, but when you can have one file with only the year present, and you get a new file with a complete (but wrong!) date year/month/day in the resulting file.

see: https://bugs.launchpad.net/soundconverter/+bug/677291
Comment 1 Gautier Portet 2010-11-23 09:57:44 UTC
sorry: "this is NOT a big deal" :)
Comment 2 Sebastian Dröge (slomo) 2010-11-23 10:01:16 UTC
Now that we have GstDateTime this should be possible to fix
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2010-11-27 18:47:48 UTC
I think it would make sense to do this case by case. Can you describe as many different cases where you know it happens and eventually provide test clips?
Comment 4 Tim-Philipp Müller 2010-11-27 19:20:42 UTC
> Now that we have GstDateTime this should be possible to fix

Right, but we still need to add API to determine the 'granularity' of the date time, ie. which fields are set (YYYY, YYYY-MM, YYYY-MM-DD, YYYY-MM-DD + TIME)
Comment 5 Tobias Rapp 2011-02-25 16:02:01 UTC
Maybe level of 'granularity' can be described from top (year) to bottom (microseconds): GRAN_YEAR < GRAN_MONTH < ... < GRAN_USEC ?

The timezone should possibly have its own "is-defined" flag as it can be present even if the time is not specified down to the microsecond.
Comment 6 Tim-Philipp Müller 2012-06-16 16:48:38 UTC
This has been implemented in 0.11/1.0 (git master):

commit 5b37641cbcdec1ad744404800fca87fa8a7d60e9
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Tue Jun 12 23:52:02 2012 +0100

    datetime: clean-ups and new API adjustments
    
    Remove constructors we don't want:
    gst_date_time_new_ymd_h() because we don't want to
    support hour-only for now;
    gst_date_time_new_ymd_hm() because we don't want to
    add constructors with time info where the caller doesn't
    have to think about what timezone the time is in.
    Lots of compulsive clean-up. Docs fixes. Replace
    has_minute() and has_hour() with has_time().

commit 000ebef2f4d649015f6689a13e32d016d126e78f
Author: Oleksij Rempel <bug-track@fisher-privat.net>
Date:   Tue Jun 12 22:35:42 2012 +0200

    datetime: allow GstDateTime where not all fields are set
    
    In order to deserialise and re-serialise dates and date times
    from tags properly, we need to be able to express partial
    dates (e.g. YYYY or YYYY-MM) and date times.
    
    We only support partial date times where all the more
    significant fields above the first unset field are set
    (e.g. YYYY-00-DD is not supported).
    
    Calling _get_foo() when foo is not set is not allowed
    any more, callers need to check which fields are set
    first.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=677757


Still needs some work in the various tag readers/writers though.