RFC: Timestamps/timezones proposal

Charles Day cedayiv at gmail.com
Thu Jul 17 12:10:04 EDT 2008


On Thu, Jul 17, 2008 at 1:37 AM, Christian Stimming <stimming at tuhh.de>
wrote:

> Am Mittwoch, 16. Juli 2008 22:04 schrieb Charles Day:
> > OK, here's an idea. I'm interested in seeing the reaction. Maybe it's
> > stupid, maybe not.
> >
> > 1. Store transaction timestamps in UTC.
>
> Transactions currently store two timestamps, see
> http://svn.gnucash.org/docs/HEAD/structtransaction__s.html
>
>  Timespec date_entered;     /* date register entry was made              */
>  Timespec date_posted;      /* date transaction was posted at bank       */
>
> I assume we're discussion the date_posted here. For the reasons that have
> been
> discussed in the "Re: time_t" thread in length, I don't think storing this
> in
> UTC really solves the problem at hand. Instead, I propose a different
> approach:
>
>  Change the date_entered field of a transaction into a GDate.
>

I'm not trying to ignore the GDate solution. I just want to consider any
alternatives so we can compare.

Using GDate would of course be much better than the status quo, but it also
removes the option to capture the posting time of day. The other possible
option is an improved design around timestamps, so I want explore that
option and see what conclusions can be reached, even if the conclusion is
"timestamps won't work".

> 2. Set a timezone for each account.
>
> I think the case of different account timezones inside the same gnc_book is
> an
> extreme corner case. Wait a second - that's the European point of view. Is
> this different in North America? From a European point of view, I think the
> UI necessary to handle one timezone per account is an insane overkill that
> no
> one will understand at all. Instead, if at all, a book should store one
> timezone and that's it.
>

There can be a "preference" for default time zone. Only users that actually
have a need for timezone differences would need to mess with per-account
-settings. Storing one timezone per book could be OK too, but users with
accounts in a variety of timezones (like me) might be interested in more
flexibility.

> 3. In account registers, the transaction date is displayed according to
> > that account's timezone.
>
> If date_posted were a GDate, the transaction date is simply that date.


I get that, but if I transfer funds from US to Australia, in one account the
date will be wrong most of the time. Going the other way, what if I transfer
some cash from Australia to the US, then fly to the US (arriving before I
left, according to the calendar) then immediately spend the money?
Depending on how you choose to use GDates, I could be spending the money in
the US before I even transfer it there. Obviously the way around that is to
just let the date be off in one account.  (I'm used to that sort of fudging
by now, and it doesn't bother me.)


> > 4. In account registers, entering/altering a transaction date is always
> > done in terms of that account's timezone.
>
> Yes.
>
> > 5. Add report options allowing the user to pick a reporting time and
> > timezone
>
> I don't think this could be presented in a UI that isn't grossly
> misunderstandable to the vast majority of users (though again, that's the
> point of view of contries which don't have more than one timezone). Instead
> I
> would simply choose the local timezone for each report, as it is currently.
>

Use the same default as the accounts. Most users won't know/care, but offer
the choice to those that do.

> 6. Allow users to specify the time of day for transactions. (Perhaps
> > optional.)
>
> No, even though this is being asked for in that very old bug, I don't think
> this will improve the situation, let alone the UI.
>

Personally, I don't have much need for entering a variety of times. But the
UI doesn't need to visibly change much. I would suggest that the register
display stay the same, and those who want to see or enter a time of day
could do so by clicking the drop-down button in the register's date field
(the pop-up calendar also allows time entry, if we choose to allow it). On
reports, display of time of day would be off by default.

> For example, as I move
> > around the globe, altering my computer's timezone wouldn't affect how
> > transactions are displayed
>
> This, as everyone confirmed so far, is still clearly a bug and needs to be
> fixed in any case.
>
Regards,
>
> Christian
>

-Charles


More information about the gnucash-devel mailing list