On Thu, Jul 17, 2008 at 11:22 AM, Nathan Buchanan <[EMAIL PROTECTED]> wrote:
> > > On 7/17/08, Charles Day <[EMAIL PROTECTED]> wrote: >> >> On Wed, Jul 16, 2008 at 9:07 PM, Nathan Buchanan <[EMAIL PROTECTED]> >> wrote: >> >>> Hi! >>> On Wed, Jul 16, 2008 at 4:04 PM, Charles Day <[EMAIL PROTECTED]> wrote: >>> >>>> OK, here's an idea. I'm interested in seeing the reaction. Maybe it's >>>> stupid, maybe not. >>> >>> >>> I havn't looked at the time code used in gnucash, so whatever I say is >>> entirely as an observer here. Generally I like the idea, though I don't know >>> the work involved. >>> >>>> >>>> >>>> 1. Store transaction timestamps in UTC. >>> >>> This seems sane to me. I would assume they'd be stored as ISO8601 strings >>> or as seconds from the epoch (though that's somewhat less readable). In >>> theory, you could store it as any ISO8601 string (similar to what we have >>> now, I think), but this would only indicate a "point in time". The timezone, >>> while useful in converting to UTC, would otherwise be meaningless. >>> >>>> >>>> 2. Set a timezone for each account. >>> >>> ok. >>> >>> What happens when the user changes an account's timezone? Do all the >>> timestamps for that account get updated? Or do the timestamps remain the >>> same, but the time displayed potentially changes? >>> >> >> Timestamps remain the same and the value displayed changes. >> >> >>> Also, how would we deal with a transfer from an account A in timezone A >>> to an account B in timezone B? What time (hour) would get assigned? Then >>> what happens when the user decides to change the timezone for account A? >>> >> >> If you enter the transfer in register A, you are entering in terms of A's >> timezone. If you enter it in B, you're using B's timezone. The hour could be >> defaulted by a preference unless the user want to actually enter a different >> one (which I think should be allowed; otherwise I see no point using >> timestamps at all). >> > > ok, though what happens when the user decides to change the timezone for > account A? (eg. I ask the bank to transfer my account from their Saint > John's branch to their Vancouver branch, 5 timezones apart?) What happens to > the timestamps and dates displayed then? > The timestamps don't change. Only the value displayed. > > Nathan > > We would simply have to decide on these things and document them clearly. >>> >>>> >>>> 3. In account registers, the transaction date is displayed according to >>>> that >>>> account's timezone. >>>> 4. In account registers, entering/altering a transaction date is always >>>> done >>>> in terms of that account's timezone. >>> >>> sounds good. >>> >>>> >>>> 5. Add report options allowing the user to pick a reporting time and >>>> timezone >>> >>> ok. >>> >>>> >>>> 6. Allow users to specify the time of day for transactions. (Perhaps >>>> optional.) >>> >>> nice, but would probably not get used way to much - we would need to pick >>> a sane default (which we would have to do anyway) >>> >> >> Exactly. We pick a sane default, but allow users to enter a different one >> if they choose. From an implementation standpoint, I believe collecting the >> time data is actually easy to do; the code to support that is already there >> but not activated in registers. >> >> >>> Nathan >>> >>>> >>>> >>>> Suppose this was already done... How would it help you out or screw you >>>> up? >>>> >>> >>>> I have accounts in several timezones, and I can see a few ways that this >>>> would help me already compared to the status quo. For example, as I move >>>> around the globe, altering my computer's timezone wouldn't affect how >>>> transactions are displayed >>>> >>>> Cheers, >>>> Charles >>>> >>> >> -Charles >> > > > > -- > <><><><><><><><><><><><><><><> > "Even if you are on the right track, you'll get run over if you just sit > there" - Will Rogers > _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
