Fw: Re: RFC: Timestamps/timezones proposal

David T. sunfish62 at yahoo.com
Fri Jul 18 19:54:02 EDT 2008


Meant to include the list.


--- On Fri, 7/18/08, David T. <sunfish62 at yahoo.com> wrote:

> From: David T. <sunfish62 at yahoo.com>
> Subject: Re: RFC: Timestamps/timezones proposal
> To: "Derek Atkins" <warlord at MIT.EDU>
> Date: Friday, July 18, 2008, 4:53 PM
> Derek, when I look at bug 89439, I see that OP wants to be
> able to sort transactions in a particular order, and change
> that order after the fact.  NONE of the proposals really
> address that need, since using any sort of timestamp to set
> the order doesn't necessarily enable the user to manage
> or change the transaction order after the fact any better
> than right now. Moreover, I would imagine that allowing
> this sort of ex post facto modification of the transaction
> record might undermine the perceived reliability of the
> data stored in Gnucash. For those reasons, I would agree
> that the bug should be set WONTFIX.
> 
> That said, I do think that using a bare date for
> establishing the transaction date with a timestamp to note
> the time that the transaction was entered in the system
> would be useful (although, truth be told, I wonder how such
> a timestamp would turn out in a QIF/OFX import). Perhaps
> having a Transaction Date, a Created timestamp (preferably
> unmodifiable), and a Record Modified timestamp (on which
> the register is sorted) would be the way to go. That way,
> the OP could re-order transactions by editing them. This
> sort of data tracking is common in database environments;
> perhaps it's advisable here.
> 
> Overloading the transaction date to do double duty for both
> external--LEGAL--recordkeeping purposes AND internal
> transaction-sorting purposes obviously CAN be done, but it
> requires an entire set of protocols and caveats to
> maintain, as all of Charles' explanations underscore.
> Why make all this trouble, when you could store two
> separate data elements--one for the legal recordkeeping
> purposes, and a SECOND one to sort the transactions in the
> register?
> 
> David
> 
> --- On Fri, 7/18/08, Derek Atkins <warlord at MIT.EDU>
> wrote:
> 
> > Bug #89439
> > 
> > Now, perhaps we might conclude that we can close 89439
> as
> > WONTFIX.
> > But it's certainly (to me) a compelling reason.
> > 
> > -derek


      


More information about the gnucash-devel mailing list