Date or Date-and-time for transactions

[Derek Atkins]

Christian Stimming <christian at cstimming.de> writes:

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

We sort first by "Post Date" (which GnuCash canonicalizes internally to
IIRC 'noon' (or possibly midnight -- I don't recall offhand), then
"Number", and then "Entry DateTime" which is the internal Date+Time when
the transaction was entered into GnuCash.

So yes, we are sorting by Timespec for the Post Date, but all entries on
the same Date should have the same Timespec setting for the Post Date.

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

Agreed, a Post Date should be a "Date".  There is an open RFE from about
a decade ago to allow a "Post Time", but that's never really been
implemented and opens a large can of worms (which, honestly, has already
been opened).

IMHO the Post Date should be an actual Date, and not a Timespec.  But
changing the data format is -- challenging.  ;)

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available