GNOME Bugzilla – Bug 170777
use GST_TYPE_DATE for GST_TAG_DATE
Last modified: 2005-10-13 19:32:12 UTC
currently GST_TAG_DATE specifies the date in julian calendar days, which just
isn't a very good idea, because it's very easy to use wrongly: as it's just a
normal int, app and plugin writers tend to just read/store the year there
instead of a date in julian calendar days (see bug #170306 for example).
We might want something like GST_TYPE_DATE that wraps GDate instead.
Another good reason to have GST_TYPE_DATE is because that would allow us to do
date string <=> date conversion in a GValue transform function instead of
replicating the same code all over the place and special-casing GST_TAG_DATE.
FWIW, GLib-2.8 will have a G_TYPE_DATE that wraps GDate. I guess 2.8 won't be
the minimum requirement for 0.10 though, will it?
I see no problem with requiring 2.8.
It's likely that we'll require 2.8 for other reasons, especially if they finally
apply the atomic refcounting patch.
Considering they have applied the atomic refcounting patch, requiring 2.8 looks
even more likely. Targeting for 0.9.x.
Added GST_TYPE_DATE, a boxed type that wraps GDate, and the usual bunch of
utility functions along with a hack that checks that developers don't
accidentally use G_TYPE_DATE where GST_TYPE_DATE is required.
Now the only thing that needs fixing is _gst_tag_initialize() and the various
Fixed _gst_tag_initialize() and all plugins now (at least those that handled the
julian stuff right).