Date-fix (was: GnuCash XML spec)
John Ralls
jralls at ceridwen.us
Fri Nov 9 17:22:11 EST 2012
On Nov 9, 2012, at 12:41 PM, "Derek Atkins" <derek at ihtfp.com> 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.
Regards,
John Ralls
More information about the gnucash-devel
mailing list