Charles, What impact would your proprosal have on reports?
Alex > Message: 13 > Date: Sat, 19 Jul 2008 05:52:05 -0700 > From: "Charles Day" <[EMAIL PROTECTED]> > Subject: Re: RFC2: Date/Time proposal > To: [EMAIL PROTECTED] > Cc: GnuCash Devel <gnucash-devel@gnucash.org> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, Jul 18, 2008 at 11:28 PM, Nathan Buchanan <[EMAIL PROTECTED]> wrote: > >> >> >> On 7/19/08, Charles Day <[EMAIL PROTECTED]> wrote: >>> >>> I'm going to go ahead and throw out another proposal for comments. I'm >>> calling this RFC2. Unless specifically stated, all that follows refers to >>> transaction posting dates and times only. >>> >>> Since to my knowledge the feature of having a "time zone per account" has >>> not actually been requested by any user, I'm going to leave that >>> completely >>> out of this proposal. However, if there ever was a need for that feature >>> in >>> the future, this proposal is readily extensible to support that. >> >> >> >> First off, I agree that for most (maybe all?) cases the timezone per >> account is not needed. That being said, I was a bit nervous removing the >> option of adding timezones in the future, so I think this proposal better >> addresses the needs without restricting things in the future. >> >> Here's what I was thinking. The general idea is to allow "date only" >>> functionality, but also allow optional entry of a time of day: >>> 1. Let there be a checkbox preference named "Show transaction posting >>> times". Off by default. >>> 2. When this preference is off, registers look the same as today; a time >>> of >>> day is not seen and cannot be entered. >>> 3. When this preference is on, users can enter a posting time of day on >>> any >>> transaction, but do not have to. >>> 4. For each transaction, if a time of day has not been entered then the >>> GnuCash data file will only save the date. Otherwise, both date and the >>> time >>> of day will be saved. >> >> >> This is likely to become messy in the datafile: some dates without times >> and some with times. When we read this data in, we would have to keep track >> of which dates have times and which do not. I'd think it would be much >> simpler to create a default time and always write out the time (assuming, of >> course, that the user had not specified a time). And since the timezone is >> always known, there will never be any ambiguity or shifting dates. >> > > I believe several users have expressed that they do not want a time written > to their data file if they never actually entered one. That's one of the > things I am proposing to support with this proposal. Saving defaulted > transaction times would mean that when you read the file back in, you > wouldn't know which times were user-entered and which times were defaulted. > > >> 5. The user does not specify any time zone, and none is saved. >> >> >> ok, though I'd advocate that the timezone be specified (and possibly saved) >> as UTC. If we do not do this, the user may decide to change the timezone on >> their machine while gnucash is open and possibly save different data than >> was read in. >> > > Under this proposal, the time zone on the machine is completely ignored. The > time zone is a constant set internally by GnuCash. So changing the machine's > time zone is not an issue. > > >> 6. In case the user has some transactions with times and some without, and >>> needs to sort transactions by posting time, let there be a preference >>> exists >>> to determine how to treat the transactions that do not have posting times. >>> (Possible options might include treating them as if they had been entered >>> at >>> the beginning of the day, or at the end of the day, or at any specific >>> time >>> in between.) >> >> >> I'd allow a default transaction time instead, as above. >> >> Sound good? Well, here's the part you may not like. All of the above can be >>> implemented by GnuCash internally by use of a timestamp and a flag >>> indicating whether the time of day was entered by the user. Let me >>> explain: >>> A. All timestamps would use the same time zone, which never varies. Users >>> do >>> not pick the time zone. It is hard coded and is never seen in the GUI and >>> never saved to the data file. >> >> >> Unless the user changes timezones with the file open... >> > > GnuCash would ignore the system time zone. > > >> >> Nathan >> >> B. If a transaction is read from a data file and it contains both a date >>> and >>> a time, these are combined with the time zone from (A) to compute a >>> timestamp. The flag is raised to indicate that the time of day was entered >>> by the user. >>> C. If a transaction is read from a data file and it contains only a date, >>> a >>> time of day is added on according to the preference indicated in (6) >>> above, >>> and these are combined with the time zone from (A) to compute a timestamp. >>> The flag is lowered to indicate that the time of day was NOT entered by >>> the >>> user. >>> D. To display the date in the GUI, GnuCash takes the time zone from (A) >>> and >>> the timestamp, and uses them to compute the date. >> >> E. To (optionally) display the time in the GUI, GnuCash takes the time zone >>> from (A) and the timestamp, and uses them to compute the time of day. >>> F. When saving a transaction to the data file, if the flag is raised to >>> indicate that the time of day was entered by the user, then GnuCash writes >>> the date and time of day to the data file. >>> G. When saving a transaction to the data file, if the flag is lowered to >>> indicate that the time of day was NOT entered by the user, then GnuCash >>> writes only the date to the data file. >>> >>> My reasons for suggesting the continued use of timestamps internally are >>> that it makes it very easy to sort transactions by posting time, and that >>> the necessary code changes to get this done is still fairly small. So >>> there >>> is probably some reasonable chance of it actually getting done, which is >>> an >>> important factor to consider. Several of you who want to use "date only" >>> internally have made fair points about simplicity, but I have made the >>> point >>> that the effort of getting from here to there would be much larger. So you >>> would have to ponder the question of who would devote the necessary time >>> for >>> that larger effort. >>> >>> OK, now praise this, ask questions, or rip it apart (more likely) as you >>> see >>> fit. Thanks to everyone so far for remaining fairly civil while discussing >>> this potentially incendiary topic. >>> >>> Cheers, >>> Charles >>> >> > -Charles > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
