Date or Date-and-time for transactions
Christian Stimming
christian at cstimming.de
Wed Nov 28 05:45:30 EST 2012
Am Dienstag, 6. November 2012, 07:28:25 schrieb John Ralls:
> > By the way, I still think it's a design flaw of the current gnucash data
> > model to use time_t as a representation of a Transaction's date.
> > Instead, we should use a date type instead of a date-and-time type. For
> > one thing, using a date type would get us rid of the ever-lasting
> > timezone issue ("date of txn changes with changing timezone"). Also,
> > the UI offers only display and entering of the date, not a
> > date-and-time. And additionally, we would get rid of the 2038 issue.
>
> ... Another problem is that I think we sort
> Transactions based on posting time unless there's a number entry, in which
> case it's date - and - number. Yet another is that time zone affects date,
> too. It's already Wednesday in Australia, for example.
Hm... do we really sort by posting time (well, firstly by posting date,
secondly by posting time-of-day), even though the posting time-of-day can
never be modified? I thought we sort by posting date and secondly by entered-
time-and-day. I thought the posting time-of-day has no function anywhere,
except that it's causing trouble with the timezone issue.
> I think the solution to the floating date problem is to introduce a
> preference for a "home" timezone and make Gnucash always display dates in
> that timezone. That also addresses the future
> multi-users-in-multiple-timezones version of the problem.
I don't think this is the correct mapping of the business problem into the
code domain. I mean, does an accountant say "this transaction happens on the
day x in timezone y?" My understanding is that a business' transaction happens
on some given day x in the book and that's it. The timezone might be implied
by the home location of that business. But changing the home location into a
totally different timezone would sure not start to change the date of those
transactions, wouldn't it? Because of this, I would prefer to assume a
transaction has a fixed date, which will be interpreted as exactly this date
in whatever timezone it is looked at.
> For phase 2, I'd like to get rid of TimeSpec/GncDate/gnc_time_t /GDate and
> replace it with GDateTime everywhere.
Note that GDateTime is still relatively new in glib, which is why we have this
mixup in gnucash, but we should now use it as much as possible. I agree a
transition to GDateTime is a good goal, with the exception of the transaction
date. In my opinion the business logic here requires the representation of a
date only, without any time-of-day attached and also without any "date inside
a special timezone" attached. But maybe we need some accountant input here:
Does that "date of a transaction" change if significantly different timezones
are involved? Or is the date fixed regardless of from whatever timezone it is
looked at? If the latter is true, neither time_t nor GDateTime is suitable but
rather something like a julian day.
Regards,
Christian
More information about the gnucash-devel
mailing list