Derek Atkins wrote: > Graham Leggett <[EMAIL PROTECTED]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
