Date-fix (was: GnuCash XML spec)

[John Ralls]

On Nov 6, 2012, at 7:28 AM, John Ralls <jralls at ceridwen.us> wrote:

> 
> I'm keeping Timespec/GncDate for now because I'm not ready to redo all of the Timespec-based code in engine. Similarly, I wrote gnc_localtime etc as a drop-in replacement for g_localtime and friends. That's the only way I'm going to be able to finish this first phase by the end of this year. Hmm, I've been converting time_t to gint_64, but I guess I should make a typdef gnc_time_t so that I can find them all for phase 2.
> 

I'm having second thoughts about this: The nanoseconds field is a pain, it's always 0 except in test-gnc-date.c (which uses a random number generator capable of overflowing even 64-bit times) and it's never stored.

Any objections to converting all Timespecs to time_t64? (I decided that time_t64 is clearer than gnc_time_t.)

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.

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.

Regards,
John Ralls