Date-fix (was: GnuCash XML spec)

John Ralls jralls at
Fri Nov 9 17:22:11 EST 2012

On Nov 9, 2012, at 12:41 PM, "Derek Atkins" <derek at> wrote:

> John,
> On Fri, November 9, 2012 2:47 pm, John Ralls wrote:
>> Any objections to converting all Timespecs to time_t64? (I decided that
>> time_t64 is clearer than gnc_time_t.)
> As opposed to time64_t?

Maybe. There's int64_t in sys/types.h, but I don't know where (or if) that's specified anywhere. But it's intuitively obvious that int64 means "64-bit integer". Is time64 equally intuitive? 

OTOH, GLib sticks 64 (or 8, 16, or 32) on the end of base types (e.g. gint64), and time_t is sort-of a base type.

Shrug. Doesn't really matter, a single run of find can switch from one to the other.

>> Another issue which I just discovered is that we're using GConf to store
>> time_t values for the start and end of fiscal years. GConf doesn't have an
>> interface for storing longs, never mind long-longs -- and neither does its
>> sort-of successor, GSettings.
> There are two issues here.  I think the biggest issue is that we're
> actually storing a full date instead of just a Day/Month.  IMHO the Period
> entry should just be, e.g. Jan 1 - Dec 31.  Or July 1 - June 30.  I don't
> think we should be storing a year, per-se, unless someone has a "short
> year".  But honestly do we need to support "short-year" periods?  It's not
> like we really have a "Period" object, so there is no historical way to
> mark the period for a particular transaction.
> Moreover, I don't think the period should be in the Preferences.  It
> belongs in the File Properties.  The reason is that if you're managing
> different data files for e.g. different companies, they may have different
> start-of-the-year dates.
>> I can see two ways of dealing with this: We can switch from using GConf to
>> storing the fiscal-year in Book (it probably belongs there anyway) or we
>> can switch from storing it as a time_t to a GDate Julian (the number of
>> days elapsed in the common era) or we can do both. I'm inclined to do
>> both: Book would load from the GConf value if its fiscal-year value isn't
>> set, the preference dialog would retrieve and set from Book instead of
>> GConf, etc.. I haven't really dug in to this part, so I've got a rather
>> simplistic view ATM, so there may well be something else I'm missing.
> How about storing it in the book, and storing it as a pair of Month/Day
> tuples?  :)   This also maps nicely into "current Period" and "last
> Period".  :)

How about what the government calls a "Julian Day", the number of days after 31 Dec? I would stipulate that 29 Feb is ignored, so that 60 is always 1 March. That's easier to store in SQL than a tuple.

John Ralls

More information about the gnucash-devel mailing list