Closed Bug 323063 Opened 19 years ago Closed 8 years ago

FTP file dates have wrong year for recent files, e.g., Dec 2005 says 2006.

Categories

(Core Graveyard :: Networking: FTP, defect)

x86
Windows XP
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: Richard_Landau, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

FTP list of files, some old and some recent.  Recent files are listed
by ftp "ls -l" as date and time instead of date and year.  However,
Firefox seems to put the current year number into those dates.  Files
that were created in, for example, December 2005 are listed incorrectly 
as "December 2006."  (It is currently January 2006.)

Reproducible: Always

Steps to Reproduce:
1. Go to ftp site with files created near the end of last year, Sept-Dec 2005.
2. Inspect year numbers of file dates in listing.
3. Files less than six months old, but in 2005 rather than 2006, will show date of, e.g., December 2006 (in the future).  
Actual Results:  
Firefox 1.0.6, 1.0.7, and 1.5 on WinXP report (in part)

12/12/04 12:00AM         29,064 wimstype-20041212.xsd
02/20/05 12:00AM         25,596 wimstype-20050220.xsd
09/12/06 05:51PM         28,567 wimstype-20050912.xsd
12/09/06 05:34PM         29,930 wimstype-20051209.xsd

Expected Results:  
ftp "ls -l" on WinXP and Ubuntu Linux report

-rw-r--r--    1 ftp      ftp         29064 Dec 12  2004 wimstype-20041212.xsd
-rw-r--r--    1 ftp      ftp         25596 Feb 20  2005 wimstype-20050220.xsd
-rw-r--r--    1 ftp      ftp         28567 Sep 12 17:51 wimstype-20050912.xsd
-rw-r--r--    1 ftp      ftp         29930 Dec 09 17:34 wimstype-20051209.xsd

Note that the dates in "recent" format (e.g., "Dec 09 17:34" 
instead of "Feb 20  2005") are given the wrong year 
when translated by Firefox FTP display, that is 2006 vs 2005.  

It is probably the case that code simply substitutes the 
current year number, 2006, for dates in recent format, but 
the recent September and December were 2005.  

(Internet Exploder, perish the thought, gets it right.)
Assignee: nobody → dougt
Component: File Handling → Networking: FTP
Product: Firefox → Core
QA Contact: file.handling → benc
Version: unspecified → Trunk
Bug 236365 was about the opposite direction, year in the past, hm...
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060110 Firefox/1.5

I see the correct dates here (1.8 branch build on Linux), so I guess this WFM.

wimstype-20041212.xsd  	29 KB  	12/12/04  	00:00:00
wimstype-20050220.xsd 	25 KB 	02/20/05 	00:00:00
wimstype-20050912.xsd 	28 KB 	09/12/05 	17:51:00
wimstype-20051209.xsd 	30 KB 	12/09/05 	17:34:00

I don't even know how to get the kind of output you quoted (with the dates in front and exact byte lengths) in Firefox...
I see correct behavior with Firefox 1.5.0.1 branch nightly on Win2K and Firefox 1.6a1 trunk nightly on WinXP.  Do you have any extensions installed that might be affecting this?  If you go 'about:config', what is the value of network.dir.format? (the default is 2)
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060107 SeaMonkey/1.5a

File: wimstype-20050220.xsd  	25 KB  	20.02.05  	00:00:00
File: wimstype-20050912.xsd 	28 KB 	12.09.05 	17:51:00
File: wimstype-20051209.xsd 	30 KB 	09.12.05 	17:34:00
mass reassigning to nobody.
Assignee: dougt → nobody
We are in a period where ftp is clearly deprecated and in general, making changes to the code is riskier than letting it ride unless there is a patch and reviewer available to make a good judgment about it. So I'm going to wontfix ftp bugs related to enhancements, interop errors, etc.. We will be better off putting our energy into including a different js based ftp stack.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.