timeConvert does not always work on 32-bit GHC

[trofi]

One of the fallouts of vincenthz/hs-asn1#12 is the following:

Running the following

Prelude> import Data.Hourglass
Prelude Data.Hourglass> timeConvert (timeConvert (Date {dateYear = 2046, dateMonth = May, dateDay = 1}) :: Elapsed) :: Date

x86_64-linux-ghc-7.10.2 yields:

Date {dateYear = 2046, dateMonth = May, dateDay = 1}

i686-linux-ghc-7.10.2 yields:

Date {dateYear = 1910, dateMonth = March, dateDay = 25}

[trofi]

Int64 -> Int32 truncation happens in Data/Hourglass/Internal/Unix.hs
in function rawGmTime where time_t overflows 32 bits and silent truncation happens.

I've slightly changed it to make an error clearer:

rawGmTime :: Elapsed -> CTm
rawGmTime (Elapsed (Seconds s)) = unsafePerformIO callTime
  where callTime =
            alloca $ \ctmPtr -> do
            alloca $ \ctimePtr -> do
                poke ctimePtr ctime
                r <- c_gmtime_r ctimePtr ctmPtr
                if r == nullPtr
                    then error "gmTime failed"
                    else peek ctmPtr
        ctime | fromIntegral (maxBound :: CLong) < s = error $ "CLong overflow in rawGmTime: " ++ show (maxBound :: CLong, s)
              | otherwise                            = fromIntegral s

Results to:

*** Exception: CLong overflow in rawGmTime: (2147483647,2408745600)

[vincenthz]

sadly, I'm not sure that is worth fixing; specially by raising a dynamic error. also technically this hasn't nothing to do with a CLong. CLong could be 32 bits, when CTime is 64 bits

[vincenthz]

Closing, because I don't think there's any more efforts to put in this.
This is just an linux ABI problem (and other unixes that use 32 bits ctime), stop using the i386 ABI, and instead move to linux x32 ABI (32 bits with 64 bit ctime) or x86-64, or any other ABI that has 64 bits ctime.