On Mon, 17 Apr 2000, Don Sanders wrote:
> Maybe
>
>  void DwDateTime::_FromUnixTime(DwUint32 aTime) {
> -    DwUint32 t = aTime + mZone*60;
>  #if defined(USE_PORTABLE_GMTIME)
> +    DwUint32 t = aTime + mZone*60;
>      struct tm tt
>      my_gmtime_r(&t, &tt);
> #elif defined(HAVE_GMTIME_R)
> +    time_t t = aTime + mZone*60;
>     struct tm tt
>     gmtime_r(&t, &tt);
> #else
> +    time_t t = aTime + mZone*60;
>     struct tm tt = *gmtime((time_t*)&t);
> #endif
>
> might be better (though I haven't tested this and could be wrong).

Yes. If we are looking at it anyway, we better remove this whole 
PORTABLE_GMTIME thing and add a autoconf test for HAVE_GMTIME_R.
Then the code makes sense. Although it is sort of stupid to debug code that 
nobody uses :-]

> @@ -720,7 +720,7 @@ void KMMessage::setDate(time_t aDate) {
>    KMMessageInherited::setDate(aDate);
> -  mMsg->Headers().Date().FromUnixTime(aDate);
> +  mMsg->Headers().Date().FromCalendarTime(aDate);
>    mMsg->Headers().Date().Assemble();   mNeedsAssembly = TRUE;   mDirty =
> TRUE; </quote>
>
> Where in mimelib/datetime.cpp
> void DwDateTime::FromUnixTime(DwUint32 aTime)
> void DwDateTime::FromCalendarTime(time_t aTime)
>
> So before my change KMail was passing a time_t into a function that
> expected a DwUint32. (And this caused KMail to crash on Alpha).

Actually that shouldn't be a problem. The compiler should do an automatic 
cast. (It might not be Y2K38 proof though >:-) 

> KMail no longer uses the FromUnixTime function so I guess it won't be
> affected by your change. So this discussion isn't of critical
> importance. But I felt like looking into a bit more anyway.

Well, better get it right now than get bitten by it again in the future when 
someone decides to use that nice function :-)

Cheers,
Waldo