Admittedly this is most likely due to a server-side 
problem, but I was unable to figure out which RFC 
covered the MDTM command/response definition.  

The server:
 (Version wu-2.4(4) Thu Jun 18 14:15:17 PDT 1998) 
returns from MDTM a string like:
"213 191010831020526" 
instead of:
"213 20010831020526"

which cause the following code to fail at clock scan 
(the following lines are split for entry width):

    scan $clock "%4s%2s%2s%2s%2s%2s" \
              year month day hour min sec
    set clock [clock scan \
         "$month/$day/$year $hour:$min:$sec" -gmt 1]


I do not know how widespread this response may be, but 
the code could be modified to handle it by replacing 
the "scan $clock ..." line with:

    if { [string length $clock] == 15 } {
        scan $clock "%2s%3s%2s%2s%2s%2s%2s" \
                  cent year month day hour min sec
        set year [expr ($cent * 100) + $year]
    } else {
        scan $clock "%4s%2s%2s%2s%2s%2s" \
                  year month day hour min sec
    }

Logged In: YES 
user_id=75003

Patch committed to head.

File Added - 12951: ftp_modtimepp.diff

Logged In: YES 
user_id=75003

Enclosed the final patch.

Logged In: YES 
user_id=75003

This is definitely a server problem. I have seen that in
some RISKS digests as amusing examples of bad Y2K patches.

Yeah, I guess we can accomodate the servers. And also a nice
log message.