On Wed, Aug 6, 2008 at 9:33 AM, Charles Day <[EMAIL PROTECTED]> wrote:
> Previously I proposed an initial fix for the "posting time" bug (#137017) > that involved no new features and use of a fixed time zone of UTC > internally. See: > https://lists.gnucash.org/pipermail/gnucash-devel/2008-July/023613.html > > After thinking about this a bit longer, I realized that using UTC > internally could throw off the prices used in reports. If the report time is > UTC, then prices get pulled from the price db according a UTC report time > rather than local. For example, a user in New Zealand using a report date of > Dec 31 2007 and using the "nearest in time" price source could get results > based on January 1st quotes. That's because report times would be noon UTC > (as opposed to the current default of noon local), which is midnight of the > next day in New Zealand. Hand-entered quotes have a default time of midnight > local, making January 1 quotes preferred over December 31 quotes. Similarly, > downloaded stock prices would be pulled based on comparison to noon UTC > rather than local, which is probably not what users expect. > > Now maybe this is just a reporting issue, and maybe reports could be > adjusted to select posting dates according to UTC but pull quotes based on > local. But I thought of a way to simplify the fix and so I would like to > offer yet another proposal. Once again this is just an initial set of > changes aimed at squashing the current bug without introducing any new > features. > > The goals are: > -Prevent changes to the OS time zone from causing GnuCash problems. > -Leave the file format syntactically unchanged. > -Leave the file format backwards compatible. > -Leave the door open for future time entry features by continuing to use > timestamps internally. > > Here's how I propose this would work: > 1. For backward compatibility, the current posting date format of > "YYYY-MM-DD HH:MM:SS" followed by the current OS timezone at write time > would not change. > 2. When reading each transaction from a file, if the "HH:MM:SS" part is > equal to "00:00:00" then the transaction is not bug affected and the > YYYY-MM-DD part contains the date the originally entered in the register. > 3. When reading a file, if the "HH:MM:SS" part is NOT equal to "00:00:00" > then the transaction is bug affected and must be reviewed to determine the > date the user originally entered in the register. > 4. Once the date originally entered in the register has been determined, > GnuCash converts that date into a timestamp by imposing a default time of > day of midnight and using the LOCAL time zone. > 5. Now that the file has been loaded, the user does whatever they want in > the GUI, completely unaware of what time of day or time zone GnuCash is > using internally. > 6. When the file is saved, GnuCash saves the timestamp using the current, > OS-determined time zone. > > This is essentially the same as the previous proposal, except that the > local time zone is used internally instead of UTC. I see a few benefits to > doing it this way, and one cost: > Benefit: The price quoting mechanism for reports works as expected > Benefit: The required code change is much smaller and simpler (only the > code that parses the GnuCash file must be changed) > Cost: The first goal suffers slightly - if the user changes the time zone > setting while a GnuCash is running, some transactions could appear off by a > day (but only until the file is reloaded.) > > Finally, I've already written this patch and attached it to the bug report. > See: http://bugzilla.gnome.org/show_bug.cgi?id=137017 > > I think that step 3 above can be completed without needing to stop and ask > the user for directions, but would obviously appreciate peer review and/or > testing of the patch to identify any problems. > > Comments? Is this at least better than the current code? Would this > introduce new problems not mentioned here? > Has everyone forgotten about this patch, or lost interest? After all the earlier discussion, I am a bit surprised to see no responses here or in the bug report. If this is worse than the status quo, somebody please say so. I think the patch works, but since this is a very important bug, and the fix involves massaging user data, I don't want it to be released in 2.2.7 (or ever) until someone else has tested it. Would it help if I commit the patch to SVN? Cheers, Charles _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
