On Jan 27, 2014, at 8:29 AM, Derek Atkins <warl...@mit.edu> wrote: > Gary Bilkus <m...@gary.bilkus.com> writes: > >> Given that time_t is always a signed integer value, wouldn't >> >> return (double)(time1-time2) >> >> just work anyway, at least as far as a patch for mingw is concerned? > > Is it always a signed integer? Can't it sometimes be unsigned? > > This is the "year 2037" problem, where 32-bit unsigned time rolls over. > However there is also a "Year 2106" problem, which is where 32-bit > unsigned time rolls over. I think there *are* some systems where it's > unsigned, but still 32 bits. Or at least there are apps where that is > the case. It's actually the "2038 problem", as a signed 32-bit time_t overflows at 03:14:07 2038-01-19.
Representation of time_t is up to the C library unless the application re-implements all of the standard C functions which use it including retrieving the tick count from the system clock. http://en.wikipedia.org/wiki/Unix_time#Representing_the_number reports that QNX V6 implements it as unsigned, but that it's generally implemented as signed. I don't think there's any reason to port GC to QNX. None of which matters a whole lot. We needed dates past 2038 to support scheduled transactions, so we don't use time_t. AQBanking and LibOFX aren't AFAICT concerned about far-future dates, so for the moment time_t, even 32 bit, is fine. The real problem we're dealing with here is that MinGW screwed up handling Microsoft's time_t size arrangements, effectively breaking it for 64-bit values. Until they sort that out, ISTM the solution is to coerce 32-bit time_t on 64-bit builds. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
