RFC: Timestamps/timezones proposal

[Charles Day]

On Thu, Jul 17, 2008 at 11:22 AM, Nathan Buchanan <nbinont at gmail.com> wrote:

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

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
>