On Sat, Jul 19, 2008 at 7:16 PM, Nathan Buchanan <[EMAIL PROTECTED]> wrote:
> > > On 7/19/08, Charles Day <[EMAIL PROTECTED]> wrote: >> >> 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. >> > > If we want to track whether the user entered the time or not, I think it > would be much cleaner if we had a separate flag in the datafile for that. > Inferring it from the date format seems a bit unintuitive to me. > I've done some work in industries that use YYYYMMDD with an optional HHMM tacked on the end, or even HHMMSS.SSSSSS, as an industry-wide format for passing data within and between companies. So I guess, having done that, I don't find it unintuitive. One of the ideas of this proposal is to avoid saving posting times that the user didn't enter, since a few users have spoken out against this. Another option to consider is to write the date and time out as separate fields in the data file. -Charles > Just my 2 cents. > > Nathan > > 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. >> > > ok > > 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 >> > > > > -- > <><><><><><><><><><><><><><><> > "Even if you are on the right track, you'll get run over if you just sit > there" - Will Rogers > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
