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). > Regards, > Graham -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel