Date or Date-and-time for transactions

[John Ralls]

On Nov 28, 2012, at 6:29 AM, Derek Atkins <warlord at MIT.EDU> wrote:

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

Sorry, I knew that but I scrambled post date and entry date in my head when I wrote it.

> 
>>> 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).
> 
I don't think Post Date is really an issue here: It's a user-entered date, and if its internal representation is a GDate, then there is no timezone issue if we also get rid of the timezone-aware code. Then we can also get rid of all of the gyrations to set dates to the beginning, middle, or end of the day. I'm all for using GDates for the internal representation of dates with one caveat: We have to avoid  g_date_set_time(), g_date_set_time_t(), and even g_date_set_timeval(), because they all use a 32-bit time_t. Not a big deal, just create the GDate from a GDateTime.

Entry date-time is another matter, particularly in a multi-user, multi-timezone case. Since it's used mostly for sorting, maybe we should just leave it in Z and ignore timezone altogether. That would simplify a lot of code.

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

Actually, the stored date format is an ISO8601 date-time string, so we can do whatever we want for an internal
representation. 

Regards,
John Ralls