Date-fix (was: GnuCash XML spec)

[John Ralls]

On Nov 9, 2012, at 2:46 PM, Derek Atkins <derek at ihtfp.com> wrote:

> 
> On Fri, November 9, 2012 5:22 pm, John Ralls wrote:
> 
>>> 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.
> 
> Sure, but what happens on leap year?  For example, if the user specifies
> March 1 -> Feb 28 (60, 59) then what happens on a leap year?  If 59 always
> refers to Feb 28th, where does Feb 29 fall?  And if you only specify one
> date (eg only specify the start or end) you have a similar problem where
> Feb29 might fall on the wrong side.  We just need to make sure that the
> rules are explicit and make sense.
> 
> I don't think anyone would ever specify Feb29 as a start date -- that
> wouldn't make sense.  So maybe come up with an algorithm that's based
> around that rule: You cannot start on Feb 29, but you can end on Feb29 if
> you start on March 1.  Do we want to support periods != 1 year?  If not we
> could, theoretically, just store the start date as a Julian Day w/o leap
> year, and compute the end date as the day earlier one year later.

You already said that we don't really want to support "short" years, and I agree, so yes, let's just store one day. 

Incidentally, I think I was mistaken about where fiscal year is stored: That *is* in the Book's KVP. It's then combined with the Accounting Period setting in prefs (i.e., gconf) to calculate the dates of the accounting period. There's the option of overriding that by setting a fixed-date beginning and end to the accounting period in prefs, and that's where the problem with (time_t64|time64_t) comes in.

Regards,
John Ralls