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.
> Regards,
> John Ralls
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
