time_t

[Phil Longstaff]

Derek Atkins wrote:
> Graham Leggett <minfrin at sharp.fm> writes:
> 
>> Nathan Buchanan wrote:
>>
>>> I'm a bit out of my league here...but I believe a long (or long int)
>>> is defined to be a minimum of 32 bits - so if you're still using a
>>> 32 bit system(?) (or processor?) you may still get a 32 bit time_t.
>> You're right - the 64 bit RHEL5 system showed sizeof(time_t) to be 8,
>> while Leopard on my Powerbook G4 said 4, as did RHEL4/i386.
>>
>> Looking at what APR (the Apache portable runtime) does with its
>> portable version of time_t, it explicitly defines it as a 64 bit
>> signed type. I suspect gnucash may have to do the same.
> 
> GnuCash has a 64-bit time type, called "Timespec".  The problem
> is that over time we've moved more and more code to using general
> widgets that use time_t instead of Gnucash custom widgets that
> use Timespec.
> 
> Eventually the OSes will upgrade time_t to 64 bits at which point
> we're fine.   We store dates as ISO-8861 strings so #bits doesn't
> matter to our XML storage.  In SQL we should be sure to use a 64-bit
> time value (or a string).

Different database engines have different column types for storing
dates/times, so I'm using a 'YYYYMMDDHHMMSS' char string.

Phil