On Nov 9, 2012, at 12:41 PM, "Derek Atkins" <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
