[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