Reason for compose window not closing

[Warwick Smith]

I have just joined this mailing list, but saw in the archives the same
problem that I was having with the compose window not closing when sending
mail.  The mail was actually sent, although the the recipient saw the email
listed as if was sent about 20 days ago.

I have tracked down (and worked around) what was causing this and thought I
might share it - a PHP bug in the date('r') function call.

I have just reported this on bugs.php.net and the number 15362 has been
assigned to it (for those who wish to follow it).

The problem is the the date('r') call (which returns an RFC 822 style date)
is used (amongst other times) for the headers of the email message when
sending.  On my system, the timezone offset returned is *way* out and
returns +10800 (should be +1030).  This causes a buffer overflow in the PHP
code in datetime.c which was setup to only allow for the 4 digits).  This
causes the http process to die on cleanup and not return any data back to
the browser - thus giving the 'no-close' situation.

I have found this to be the case in both PHP 4.05 and PHP 4.1.1, although I
guess it would probably affect the versions between also.

There seems to me to be 2 ways of working around this.

1. strftime("%z")

The undocumented (in the PHP manual anyway) '%z' option of the strftime
function returns the timezone offset correctly (+1030), so all occurrances
of date('r') could be replaced with:
	strftime('%a,%e %b %Y %T %z')

The downside to this is that you would be using an undocumented option
according to the PHP manual.  If this is just an oversight in the doco
(probably is) then this would be the better bet.  The %z option is normally
a standard option for the strftime 'c' function (do a 'man strftime' on
unix)

2. Calculate RFC822 date using date('Z') for timezone offset

Not as nice, but this sticks with PHP standards as documented.
The date('Z') correctly returned the timezone offset seconds, so it could be
used in a common function to manually calculate the offset, then create the
RFC822 date.

There's probably better ways, but I added a new function in the Horde class
(/horde/lib/Horde.php) called rfcDate.  If no paramaters are passed, it
returns the current date, otherwise returns the date of the time value
passed.

Details:

    function rfcDate ($time = "")
    {
        // Returns the RFC-822 style date

        $rfc822Date = ($time)
                       ? date("D, d M Y H:i:s ", $time)
                       : date("D, d M Y H:i:s ");

        $tz = (date('Z') / 60);
        if ($tz < 0) {
            $tz = str_replace("-","",$tz);
            $rfc822Date .= "-".intval($tz/60).($tz%60);
        } else {
            $rfc822Date .= "+".intval($tz/60).($tz%60);
        }

        return ($rfc822Date);
    }

I just replaced all calls for date('r') with Horde::rfcDate() in the various
pages.

IMHO the date('r') is dangerous to be left in the IMP program as to the
humble beginner it appears to be IMP at fault - maybe the next version could
use an alternative?


Regards,

Warwick Smith
Electronic Services Officer / Webmaster
Email: warwick@imvs.sa.gov.au
Web:   http://www.imvs.sa.gov.au
Tel:   +61 8 82223832
Fax:   +61 8 82223147

* If it's never finished, you can't prove it doesn't work. *