On Nov 6, 2012, at 1:43 AM, Christian Stimming <[email protected]> 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
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
