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? 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
