Posting time bug fix proposal (simplified)

[Charles Day]

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?

Cheers,
Charles