Building on Windows from scratch - difftime problem found ( was datediff )

[Gary Bilkus]

On 27/01/2014 17:20, John Ralls wrote:
> On Jan 27, 2014, at 8:29 AM, Derek Atkins <warlord at MIT.EDU> wrote:
>
>> Gary Bilkus <mail at 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
>
>
The answer to the 'is it always a signed integer' question is: yes, on 
mingw it is, and since we're discussing a patch for the windows port,  
does it matter if there are any really weird unix variants which use 
unsigned ( and I do mean weird ). The problem with the simple code I 
proposed above is the edge case caused if time1 is very large and 
positive, and time2 is very large and negative, meaning the result would 
overflow even a 64 bit int before being coerced to double. But that 
isn't going to happen with any plausible use case for these libraries ( 
the only time ofx uses the function is in a minor correction of a few 
hours to the date based on some timezone subtleties as far as I can tell ).

If I were writing a library for use by the entire world, I'd care that 
time_t might be unsigned on some variant. Since I'm just trying to find 
a patch which allows gnucash to compile on Windows, and should never be 
applied elsewhere, I don't care if time_t is sometimes unsigned on unix 
boxes.

But I don't own the project, so I'm still looking for a definitive 
understanding of what is likely to be acceptable as a patch which 
eventually gets into the official repository. It's not urgent for me, 
because I have what I need now, which is a way of compiling gnucash on 
windows which works, and I can therefore start to investigate the stuff 
I wanted to do in the first place!
But I'm still happy to help if I get a clear steer.
And of course if I hit any further issues, I'll be happy to 
investigate/report

BTW, even on a 64bit machine, the mingw tools as used in geert's scripts 
produce 32bit executables. However, the only way to produce an 
executable which will work on all the supported windows OSs seems to be 
to compile on an XP box as otherwise it fails on XP with various 
complaints about missing libraries.