Posting time bug fix proposal (simplified)

Charles Day cedayiv at gmail.com
Thu Aug 14 16:51:50 EDT 2008


On Wed, Aug 6, 2008 at 9:33 AM, Charles Day <cedayiv at gmail.com> 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


More information about the gnucash-devel mailing list