RFC: Timestamps/timezones proposal

[Nathan Buchanan]

On 7/17/08, Charles Day <cedayiv at gmail.com> wrote:
>
> On Wed, Jul 16, 2008 at 9:07 PM, Nathan Buchanan <nbinont at gmail.com>
> wrote:
>
>> Hi!
>> On Wed, Jul 16, 2008 at 4:04 PM, Charles Day <cedayiv at gmail.com> 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