[Gnucash-changes] r12308 - Avoid testing dates near or after 2038

[Neil Williams]

On Monday 09 January 2006 9:06 pm, Chris Shoemaker wrote:
> Author: chris
> Date: 2006-01-09 16:06:45 -0500 (Mon, 09 Jan 2006)
> New Revision: 12308
> Trac: http://svn.gnucash.org/trac/changeset/12308
>
> Modified:
>    gnucash/trunk/src/engine/test/test-date.c
> Log:
> Avoid testing dates near or after 2038, because the qof parsing functions
> fail.

Are you sure you've identified the problem correctly?

QOF can handle dates far into the past and future, it may just be that the 
test-date routine is using the wrong method to test.

gnc-date.h:
/** The Timespec is just like the unix 'struct timespec'
 * except that we use a 64-bit signed int to
 * store the seconds.  This should adequately cover dates in the
 * distant future as well as the distant past, as long as they're not
 * more than a couple dozen times the age of the universe.  Note that
 * both gcc and the IBM Toronto xlC compiler (aka CSet, VisualAge,
 * etc) correctly handle long long as a 64 bit quantity, even on the
 * 32-bit Intel x86 and PowerPC architectures.  I'm assuming that all
 * the other modern compilers are clean on this issue too. */

If you've got ideas for a better test of the date handling routines OR if you 
find that the bug is actually in gnc_iso8601_to_timespec_gmt - let me know 
(it's a beast of a function and has a number of nasty surprises hidden inside 
it - it is certainly where I'd start hunting this kind of bug, if it exists).

At the moment, your change simply avoids your reported issue.

My problems with that approach are:
1. I don't see this issue on my test systems so I'm not sure it has been 
properly identified.
2. Your change simply avoids testing these dates - even when the tests would 
appear fine on my systems.
3. If there is a bug in gnc_iso8601_to_timespec_gmt or similar, I want to fix 
it, not ignore it!

I will not be porting this change to the test routine to the comparable test 
routine in external QOF. That continues to operate just fine.

If you can generate erroneous date handling in external QOF, please file a bug 
report for QOF (not gnucash) at SourceForge and I'll work on a fix for the 
next QOF release.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060109/c1adca5e/attachment.bin