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. Cheers -Tim
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. Cheers -Tim
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? Cheers -Tim
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.
Update: 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 plugins. Cheers -Tim
Fixed _gst_tag_initialize() and all plugins now (at least those that handled the julian stuff right).