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

[John Ralls]

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