RFC: Timestamps/timezones proposal

Charles Day cedayiv at gmail.com
Thu Jul 17 11:09:51 EDT 2008


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).


> 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


More information about the gnucash-devel mailing list