Closed Bug 239603 Opened 20 years ago Closed 8 years ago

no date is displayed in ftp listing from server type "Windows_NT" (IIS)

Categories

(Core Graveyard :: Networking: FTP, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: daniel.campos, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.6) Gecko/20040115
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.6) Gecko/20040115

The Windows 2000 ftp server provides ftp LIST in that format:

04-04-04  08:17PM       <DIR>          Ventas
01-12-04  03:23PM                80744 Ventas Diarias.zip
...

Date : month - day -year
Hour : hour (AM/PM): minute

When using Mozilla, date and time  are wrongly parsed:

Ventas  	 	03/04/04  	-33:52:44
Ventas Diarias.zip 	79 KB 	11/01/04 	-38:58:44




Reproducible: Always
Steps to Reproduce:
1. Connect to a FTP server using Windows 2000 in English configuration

Actual Results:  
Date and time are wrongly displayed

Expected Results:  
Parse them correctly
This looks like bug 223422 or bug 206214 (probably the latter)
Using the URLs from those two bugs I don't see any obvious wrong dates.
LInux 2004050707
Using command line ftp:

05-05-04  10:47AM       <DIR>          4_0_2
12-09-02  11:30AM              9501480 AcroReader51_ESP.exe
05-03-04  11:05AM               241664 backoffice.exe

Using Mozilla 1.6:

4_0_2  	 	06/05/04  	78:22:44
AcroReader51_ESP.exe 	9279 KB 	08/12/02 	-41:05:44
backoffice.exe 	236 KB 	02/05/04 	-42:40:44
I assume that is your local ftp server still.  Did you find any wrong dates @
ftp://www.rittal.de/public , ftp://download.nvidia.com/ or any other public URL?
Also, try a newer version of mozilla.  The newest langpack for es-es is 1.7rc1.
OK, finally I could test Mozilla 1.7rc1 and it shows all dates and times OK!!
Thanks, marking WORKSFORME
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
UPDATE:
Mozilla 1.7RC2, Linux

ftp ftp.asus.com
Connected to ftp.asus.com (195.33.130.135).
220 acg-co-01 Microsoft FTP Service (Version 5.0).
Name (ftp.asus.com:benc): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 Anonymous user logged in.
Remote system type is Windows_NT.
ftp> ls
227 Entering Passive Mode (195,33,130,135,18,110).
125 Data connection already open; Transfer starting.
01-23-03  10:46AM       <DIR>          incoming
01-23-03  10:46AM       <DIR>          pub


Up to higher level directory
Directory: incoming 		01/23/103 	10:46:00 AM
Directory: pub 		01/23/103 	10:46:00 AM
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Summary: Wrong date parsing ftp information from a Windows 2000 FTP server → year of date is 1xx (01-23-03 -> 01/23/103) from server type "Windows_NT"
-> new, Mac OS X, Mozilla 1.7RC2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PC → All
UPDATE:
With current Mozilla cvs trunk builds no date is displayed at all, only the time
is displayed.
Summary: year of date is 1xx (01-23-03 -> 01/23/103) from server type "Windows_NT" → no date is displayed in ftp listing from server type "Windows_NT" (IIS)
*** Bug 250434 has been marked as a duplicate of this bug. ***
mass reassigning to nobody.
Assignee: dougt → nobody
QA Contact: benc → networking.ftp
This is a dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=206214
(see comment #1)
You can observe it at different Microsoft ftp servers:
ftp://ftp.mcafee.com/ ftp> system 215 Windows_NT version 5.0
ftp://www.rittal.de/ system @ rittal: Remote system type is Windows_NT.
who both dates the directories in the 
1940's
It give the correct date with Cyberduck (mac ftp program) and with the command prompt.


This issue exists in the 3.0 Trunk.  For proof, go here: ftp://ftp.microsoft.com/Softlib/MSLFILES/

No dates whatsoever. 
I don't see this bug anymore, please mark WORKSFORME/ fixed.
Status: NEW → RESOLVED
Closed: 20 years ago8 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.