Posting time bug fix proposal (simplified)

[Charles Day]

On Thu, Aug 14, 2008 at 10:12 PM, Christian Stimming <stimming at tuhh.de>wrote:

> Am Donnerstag, 14. August 2008 22:51 schrieb Charles Day:
> > 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
> >
> > 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.
>
> Sorry for that - lost interest, and also I didn't immediately see how this
> actually changes the semantics in comparison to the status quo.
>
> After reviewing your explanation and your patch again, this seems to me a
> good
> solution for the time being.
>
> I think it should be fine to commit this into SVN (trunk), because by
> definition trunk is a development branch.
>
> But: What will happen if one goes back and forth between an old gnucash and
> trunk with this patch? This patch will change the timestamps upon first
> using, but subsequently the timestamps should be left unchanged both by old
> gnucash (say, 2.2.6) and gnucash-trunk. In gnucash-2.2.6 there shouldn't be
> any change visible as long as the local timezone stays the same as on the
> first gnucash-trunk opening of that file, right?


Correct.


> However, the local timezone
> will change at next end of daylight saving time the latest, right? Would
> this
> patch affect the displayed date in gnucash-2.2.6 after changing the local
> timezone?
>

In trunk, the timestamps are set to midnight local when the file is read.
The file writing part of the code has not changed, so unless the time zone
changes while GnuCash is open, saving the file would put midnight on all the
posting date timestamps, with the current local timezone. If you then went
off daylight savings and opened the file with 2.2.6, they would be shifted
to the previous day due to the bug, yes. Is this already a problem? Do
transactions entered during daylight savings in 2.2.6 (and before) get
thrown off by a day when daylight savings expires?


> Regards,
>
> Christian
>

Cheers,
Charles