Date-fix (was: GnuCash XML spec)

[Christian Stimming]

Am Dienstag, 6. November 2012, 10:30:06 schrieb Geert Janssens:
> > Engine unit testing has gotten set aside this summer by my realization
> > that we're running into the 2038 date issue rather sooner than we
> > expected, because it's breaking long-term SXes. Dealing with that turns
> > out to be a lot of work, but I hope to wrap it up by the end of the
> > year and get back to testing Engine and QOF.
>
> I wasn't aware of your work on the 2038 date issue. I have just
> discovered your fix-dates branch on github. That's a very big work. And
> I didn't know OS X and Windows aren't looking ahead that far. I'm
> slightly surprised glib has has no provisions for this. After all that
> is an important portability library for writing portable applications in
> C. But I'm sure you have looked around before starting your own
> implementation.

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.

That's why I added the GDate setter and getter for the txn date some time ago, 
and to back up those setters/getters with a real date type, the GDate gets 
stored at least additionally in a kvp frame... That's for sure not a permanent 
solution, but it was one step from me to move from a time_t to a real date 
type for the Transactions.

Does that fix the same issue?

Regards,

Christian