mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sai Pullabhotla <sai.pullabho...@jmethods.com>
Subject Re: [Vote] Releasing FtpServer 1.0.3
Date Mon, 28 Sep 2009 13:03:29 GMT
The LIST command in RFC959 is a big mess with no standards defined. It
is unfortunate, but I think it is important that the new versions of
the server should not break existing applications if they are relying
on the dates to get files. Since this change is definitely going to
break it, I would prefer to switch it back to the way it was.

FYI, Some FTP clients offer a setting to specify the server's timezone
to workaround this issue.

Sai Pullabhotla
www.jMethods.com


On Mon, Sep 28, 2009 at 7:37 AM, Niklas Gustavsson <niklas@protocol7.com> wrote:
> On Mon, Sep 28, 2009 at 2:20 PM, Sai Pullabhotla
> <sai.pullabhotla@jmethods.com> wrote:
>> For FTPSERVER-330, I noticed that you also changed the times returned
>> by the traditional LIST command. The LIST command now returns the
>> dates in UTC. I was wondering if we should really do this as most/all
>> FTP servers return the local date and time for the LIST command.
>
> Right, I checked the RFC and noted that it does not seem to say
> anything about what time zone to use. So, I thought we should be
> consistent in what we return. However, I do not have a strong opinion
> on this matter. Could we confirm what other FTP servers do, do they
> return different time zones for LIST and MLST? I just checked a few
> servers and the only one that supported MLST returned different
> results (since I know its local time zone I also confirmed that LIST
> returned in the local time zone and MLST in UTC).
>
>> Most
>> FTP clients are now showing times differently than what they used to
>> show, which may break things when people upgrade to 1.0.3.
>
> Right, however it does not seem like we nor the RFC has made any
> commitments as to what time zone to return. So, to me I would rather
> see us conform to how the majority of other FTP server behave. Of
> course, these might not be contradictory :-)
>
> /niklas
>

Mime
View raw message