On Tue, Aug 19, 2008 at 10:16 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Mike or Penny Novack <[EMAIL PROTECTED]> writes:
>
> > Please understand that this whole problem about "time" has me very
> confused.
> >
> > I do not understand WHAT time is under discussion. I do not understand
> > the ("business") meaning of "posting time" as never in accounting have
> > I come across the time at which the bookkeeper posts a transaction to
> > be of the least accounting meaning. Since AFAIK that is a random time,
> > I do not understand how whatever Gnucash might or might be doing with
> > the time could possibly be "in error".
> >
> > If the time of day at which the bookkeeper enters a transaction is
> > being used in some way, shape, or form as being related to the "time
> > of day of the transaction" that is simply wrong in the business sense
> > as there is no such relationship.
>
> Let me try to summarize the problem. The visible bug is that
> when you set the post date of a transaction and then reset your
> local timezone it's possible that all your dates will shift
> a day earlier or later depending on how you adjust your local
> timezone. Obviously this is a problem -- once you set a date
> it shouldn't change even if you change your local timezone, right?
>
> So that's the visible bug that we're discussing. Everything else is
> part of the underlying implementation.
>
> GnuCash doesn't store a "date" -- it stores an ISO-8861 timestamp.
> Actually, each transaction has TWO timestamps, one is the user-visible
> "post date", the other is an invisible "date entered". The latter
> is the current clock time when you create the transaction. It's only
> used for sorting and internal auditing. The user never sees this value.
> It's the former datum that is problematic, the 'post date'.
>
> When you enter a date stamp in the UI, GnuCash chooses midnight
> on that day as the timestamp to represent the day. This works
> just fine provided you never change timezones. In fact it works fine
> even if you DO change timezones provided you only move west. If you
> ever move east then you're in trouble.
>
Actually it's moving west that causes the date to change. Moving east is OK
unless you jump forward 24 hours (like Samoa to Tonga). I know, picky,
picky. -Charles
We don't want to change the data file format, which means we need to
> continue to choose and store a timestamp as part of the "post date",
> even if the timestamp itself is (currently) arbitrary. (as an aside,
> I say "currently" because there was a proposal to allow ToD entry for
> the "post date" because some users want to control when during the day
> a transaction took place.)
>
> As we have a time entry in the date stamp in the data file and cannot
> change that, the underlying question is, how do we "save" that timezone
> information when we read/write the file so that it's agnostic about
> the local timezone. And how do we do this in a backwards-compatible
> way.
>
> I hope this explains the problem sufficiently for you.
>
> Thanks,
>
> -derek
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> [EMAIL PROTECTED] PGP key available
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
