Date or Date-and-time for transactions

[Christian Stimming]

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