[Bug 34983] Internally use GDateTime for date computation

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Danielle Madeley <danielle.madeley at collabora.co.uk> 2011-03-03 21:12:32 PST ---
(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?

> It's indeed a risk, GDateTime is even a better solution since it abstract the
> timezone.

That was my thinking.

> 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?

-- 
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.