Date-fix (was: GnuCash XML spec)

John Ralls jralls at ceridwen.us
Tue Nov 6 10:28:25 EST 2012


On Nov 6, 2012, at 1:43 AM, Christian Stimming <christian at cstimming.de> wrote:

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

Well, yes and no. One problem is that GDate relies on the Posix time_t functions too, though I might rewrite it to use GDateTime instead. I'll raise that on gtk-devel-list after I get the GTimeZone Win32 tests written and the changes pushed. 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.

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'm keeping Timespec/GncDate for now because I'm not ready to redo all of the Timespec-based code in engine. Similarly, I wrote gnc_localtime etc as a drop-in replacement for g_localtime and friends. That's the only way I'm going to be able to finish this first phase by the end of this year. Hmm, I've been converting time_t to gint_64, but I guess I should make a typdef gnc_time_t so that I can find them all for phase 2.

For phase 2, I'd like to get rid of TimeSpec/GncDate/gnc_time_t /GDate and replace it with GDateTime everywhere.

Regards,
John Ralls




More information about the gnucash-devel mailing list