On Nov 6, 2012, at 7:28 AM, John Ralls <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
