[gstreamer-bugs] [Bug 594504] Need a GType of "Date AND Time AND Timezone"
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Wed Sep 9 02:06:53 PDT 2009
http://bugzilla.gnome.org/show_bug.cgi?id=594504
--- Comment #12 from Arnout Vandecappelle <arnout at mind.be> 2009-09-09 09:06:49 UTC ---
(In reply to comment #6)
> For the time in nanoseconds since start of day we would need 47 bits. Sounds
> good IMHO.
>
> For the timezone we would need 6 bits, DST 1 bit. This makes 54 bits, leaving
> 74 bits for the date itself.
>
> So offset in days from whatever date you want should be possible, so let's take
> MJD. Note however that it's not really trivial to convert this into YYYY-MM-DD
> notation because of leap years and all that. But it's not too complex, even
> GLib does it for GDate ;)
However, if it's not in nanoseconds, every operation on it is really
non-trivial.
By the way, what is the point of splitting the representation into time and
date? Makes it difficult to deal with leap seconds and DST shifts...
(In reply to comment #11)
> (In reply to comment #9)
> > Why not use a GstClockTimeDiff against the Epoch and a timezone in some
> > representation (string or enum)? That allows you to convert to anything, even
> > other calendar systems (= generalized timezone).
> >
> > I think it's important to store the UTC timestamp directly, because whatever
> > unified processing you do on it, it will probably be done on the UTC
> > timestamp...
>
> This will only allow about +-300 years from the epoch.
OK, take additional bits from the second part of the GValue. You can make a
shortcut check against 0 to ascertain that the normal GstClockTimeDiff
operations are valid.
However, I'm not even sure if dates beyond 300 years from the epoch really
need to be supported...
So, my proposal is:
data[0].v_int64 as a GstClockTimeDiff against the Epoch
data[1].v_int as a GstTimeZone enum
Regards,
Arnout
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs
mailing list