236365 - ftp date is off by one year

Status: RESOLVED FIXED

(Core Graveyard :: Networking: FTP, defect)

Description

[Adam Naumowicz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821

A file on a FTP server with access and modify time set to a date from 20 Feb
2004 till 28 Feb 2004 is shown in the ftp://... display as if the year was 2003.  

Reproducible: Always
Steps to Reproduce:
1. put any file on a FTP server that was modified between 20 Feb 2004 and 28 Feb
2004 
2. Look for the file with ftp://

Actual Results:  
The year 2003 is reported

Expected Results:  
The year 2004 should be reported

Comment 1

[Jesiah S]

do have a URL of a FTP site showing this?

Comment 2

[Heinrich Stamerjohanns]

(In reply to comment #1)
> do have a URL of a FTP site showing this?

try http://ftp.suse.com/pub/people/poeml/apache2/
dates are ok, June 30th, 2004

try ftp://ftp.suse.com/pub/poeml/apache2/
dates are WRONG, June 30th, 2004

Maybe just dates of the previous month (or week) (now it is July 2004) are
incorrectly shown?

Comment 3

[Jesiah S]

Using ftp://ftp.suse.com/pub/people/poeml/apache2/ I see this on W2K 2004070308
I also notice the time was off by two hours but I shure that is a time zone
problem with the server.
->Networking:FTP

Comment 4

[Lucas Madar]

Attachment: A patch to mozilla\netwerk\streamconv\converters\ParseFTPList.cpp to fix the off-by-one-year bug

This is a math error. I've attached a small patch to
mozilla\netwerk\streamconv\converters\ParseFTPList.cpp that should fix this
problem:

if ( (( state->now_tm.tm_month	<< 4) + state->now_tm.tm_mday) <
   ((result->fe_time.tm_month << 4) + result->fe_time.tm_mday) ) (
	    result->fe_time.tm_year--; 

The << 4 only gives 16 days per month of overlap. 

Let's say today is Sept. 2nd. That's day 2 of the 8th month.
Let's say a file is modified August 20th. That's day 20 of the 7th month. 

Today	 : 8 << 4 + 2  = 128 + 2  = 130
File Date: 7 << 4 + 20 = 112 + 20 = 132 

130 < 132 is true, so the file date is decremented by a year. It's hard to
reproduce this problem because you only have a certain window and it only works
with certain files.

Comment 5

[Boris Zbarsky [:bzbarsky]]

*** Bug 257867 has been marked as a duplicate of this bug. ***

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 157769 [details] [diff] [review]
A patch to mozilla\netwerk\streamconv\converters\ParseFTPList.cpp to fix the off-by-one-year bug

Darin, what do you think?  The reasoning makes sense to me, so...  Though it
may be better to do <<5 than *100.

Comment 7

[Darin Fisher]

Yeah, why not use '<< 5'?  Lucas?

Comment 8

[Lucas Madar]

(In reply to comment #7)
> Yeah, why not use '<< 5'?  Lucas?

No reason really, except readability if the number were ever printed out or used
in debugging. 807 (8*100+7) is easier to read/represent as 9/7 than 263
(8<<5+7). This isn't really relevant, however, so << 5 is fine.

Comment 9

[Boris Zbarsky [:bzbarsky]]

darin, I think you forgot to cc yourself... see comment 8.

Lucas, we're trying to make sure we shift the number enough so it doesn't
overlap the other one, so I think <<5 more clearly expresses that.  Could you
make that change, please?

Comment 10

[Darin Fisher]

Comment on attachment 157769 [details] [diff] [review]
A patch to mozilla\netwerk\streamconv\converters\ParseFTPList.cpp to fix the off-by-one-year bug

r=darin w/ "<< 5"

Comment 11

[Darin Fisher]

fixed-on-trunk

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #11)
> fixed-on-trunk

(for 1.8alpha6. noting this here just for reference)

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 220948 has been marked as a duplicate of this bug. ***

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 281079 has been marked as a duplicate of this bug. ***

Comment 15

[Frank Wein [:mcsmurf]]

*** Bug 284433 has been marked as a duplicate of this bug. ***

Comment 16

[Elmar Ludwig]

*** Bug 299632 has been marked as a duplicate of this bug. ***

Comment 17

[Jo Hermans]

*** Bug 308001 has been marked as a duplicate of this bug. ***

Comment 18

[Logan Ingalls]

*** Bug 314767 has been marked as a duplicate of this bug. ***

Comment 19

[Elmar Ludwig]

*** Bug 319148 has been marked as a duplicate of this bug. ***