[Bug 34983] Internally use GDateTime for date computation

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=34983

--- Comment #5 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2011-03-04 05:57:11 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> 
> > Actually, one of my goal is to replace the gint64 timestamp in TplEvent with a
> > GDateTime. As GDateTime is immutable and ref-counted, I never have to copy it.
> > As most operation simply require generating formated strings I don't even have
> > to reference it. But this requires breaking API, so I decided to do it in two
> > steps, this is first and second is to actually break the API and integrate it
> > in future 0.3.X branch.
> 
> Ahh, so it will return a (transfer none) pointer to the GDateTime that's owned
> by the object?
Yes.

> > There was no time_t in the public API, but this change removes all use of
> > time_t in the internal implementation. For 0.3.X I also plan on replacing GDate
> > with GDateTime in list return by _get_dates() and inside TplSearchHit.
> 
> Is there a problem with using GDate, it hasn't been deprecated afaik, and
> doesn't have wrapping problems, since it's just a struct. It makes sense for
> get_dates() because it's just a date (no time). It is mutable, but we only ever
> pass copies as transfer-full right?, so that's not a big deal. If you did use
> GDateTimes what timezone would you use in them?

Actually your right, only the time part of GDate has been deprecated. GDate can
be kept. Also, it allow not to care about timezone and risk that the
represented 
date changes because of current locale settings. The goal of those dates are to
present days as the user remember, so regardless of the timezone.

-- 
Configure bugmail: https://bugs.freedesktop.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.