FtpListItem.Modified turns up strange values

Mar 25, 2013 at 11:39 PM
Edited Mar 25, 2013 at 11:52 PM
Hello,

Upon retrieving list of files from FTP site, I am getting strange values for FtpListItem.Modified property:

When there actually is 2013-03-07 10:02:00, FtpListItem.Modified gives 2003.07.13. 10:02:00
When there actually is 2013-03-08 11:10:00, FtpListItem.Modified gives 2003.08.13. 10:02:00
However, these dates are retrieved correctly:
2013-03-15. 14:38:15
2013-03-25. 7:27:41

Seems that the FTPClient likes to
  • read the date from what actually is a year,
  • read the month from what actually is a date,
  • read the year from what actually is a month
That is, this strange behaviour is active unless the date (ie, actual date of the file on FTP server) goes beyond 12, in which case the date is parsed correctly.
Coordinator
Mar 26, 2013 at 2:51 AM
If you're not already, use the debug build or pull in the source and build a debug version. Add a ConsoleTraceListener and log the FTP transaction. Post the file listing back here so that I can read over it and look at adding a parser. What server software are you connecting to as well?
Mar 26, 2013 at 10:54 AM
Here it is. The dates in the listing are formatted MM-dd-yy. I don't know what is the server software, this is an outsourced service beyond my reach.

I am using Nautilus (on Ubuntu) as GUI client to this FTP server, and it shows the dates correctly. I never knew that this is not standardized in the FTP protocol - the date formats to be used in file listings, that's quite a bummer. Does the FtpClient library have the flexibility of specifying the date parsing method?
220 Microsoft FTP Service
USER MyUserName
331 Password required for MyUserName.
PASS <omitted>
230 User logged in.
FEAT
211-Extended features supported:
 LANG EN*
 UTF8
 AUTH TLS;TLS-C;SSL;TLS-P;
 PBSZ
 PROT C;P;
 CCC
 HOST
 SIZE
 MDTM
 REST STREAM
211 END
OPTS UTF8 ON
200 OPTS UTF8 command successful - UTF8 encoding now ON.
13.03.26 11:42:30 Connected.
CWD /MyWorkingDirectory
250 CWD command successful.
PWD
257 "/MyWorkingDirectory" is current directory.
TYPE I
200 Type set to I.
EPSV
229 Entering Extended Passive Mode (|||5787|)
LIST /MyWorkingDirectory
125 Data connection already open; Transfer starting.
03-07-13  10:02AM                  901 File01.xml
03-07-13  10:03AM                  921 File02.xml
03-07-13  10:04AM                  904 File03.xml
03-07-13  10:04AM                  912 File04.xml
03-08-13  11:10AM                  912 File05.xml
03-15-13  02:38PM                  912 File06.xml
03-07-13  10:16AM                  909 File07.xml
03-07-13  10:16AM                  899 File08.xml
03-08-13  10:22AM                  904 File09.xml
03-25-13  07:27AM                  895 File10.xml
03-08-13  10:22AM                 6199 File11.txt
03-25-13  07:22AM                31444 File12.txt
03-25-13  07:24AM                24537 File13.txt
226 Transfer complete.
MDTM /MyWorkingDirectory/File06.xml
213 20130315143815
MDTM /MyWorkingDirectory/File10.xml
213 20130325072741
MDTM /MyWorkingDirectory/File12.txt
213 20130325072254
MDTM /MyWorkingDirectory/File13.txt
213 20130325072406
QUIT
221 Goodbye.
Coordinator
Mar 26, 2013 at 2:02 PM
This is a regression in the IIS file listing parser, I did some work on UTC dates not that long ago and must have introduced this bug. I'll look into getting it fixed today. To answer your question, it's possible to add your own parsers to System.Net.FtpClient. There's an example project that shows how to do this. There are multiple ways to get a file listing. On servers that support machine listings, the MLSD command is used which does give a standard format listing. MLSD is the most reliable and the fastest however not all servers, such as IIS, implement it. The second way is to use LIST which is the most problematic and least reliable. LIST listings are formatted at the discretion of the server software developers. There is no standard or one size fits all solution, that's why I added a way to add custom parsers. The last way is to use NLST + MDTM + SIZE which is by far the slowest but much more reliable than LIST. In scenarios where reliability and accuracy of date/time values matters, my suggestion is to check the server capabilities flags for MLSD and if it's not available use FtpListOption.NameList | FtpListOption.SizeModify flags with GetListing() instead.

Anyway, in this particular case you have uncovered a bug and I'll look at getting it fixed.
Coordinator
Mar 26, 2013 at 2:31 PM
The latest revision should address this issue. I've tested with the file listing sample above as well as against ftp.microsoft.com. One thing to keep in mind is that the dates are assumed to be UTC so your time zone is taken into account. I've compared System.Net.FtpClient's date/time results against windows explorer's builtin ftp capabilities and they mirror each other. Some ftp clients may take the date/time values literally, no time zone adjustments.
Mar 26, 2013 at 10:20 PM
Thanks, works like charm!
Regarding the UTC, are you storing the UTC value and letting the C# to handle the local time zone adjustment, or doing the time zone adjustment calculation yourself? I mean, next week my time zone will switch from GMT+2 to GMT+3 (summer time). Will the march dates still be GMT +2, even when my current local time zone is GMT +3? That would be kind of confusing - suddenly the modified date changes for all the winter time files, perhaps triggering some "file updated" routines in somebodies code.
Coordinator
Mar 27, 2013 at 3:52 AM
The time zone adjustment is made by the .net runtime when DateTime.Parse() is called.