Here's what my wu-ftpd 2.6.0 server says for a LIST command: total 7 drwxrwxr-x 2 root wheel 1024 Apr 7 1998 bin drwxrwxr-x 2 root wheel 1024 Aug 30 1993 etc drwxrwxr-x 2 root wheel 1024 Nov 27 13:58 incoming drwxrwxr-x 2 root wheel 1024 Nov 17 1993 lib lrwxrwxrwx 1 root root 8 Nov 27 13:58 new -> incoming drwxrwxr-x 2 root wheel 1024 Nov 7 19:46 pub drwxrwxr-x 3 root wheel 1024 Aug 30 1993 usr -rw-r--r-- 1 root root 312 Aug 1 1994 welcome.msg Mozilla displays this as: 300: 127.0.0.1:1669 200: filename content-length last-modified file-type 201: bin 0 04/07/98 12:00:00 AM DIRECTORY 201: etc 0 08/30/93 12:00:00 AM DIRECTORY 201: incoming 0 11/27/99 01:58:00 PM DIRECTORY 201: lib 0 11/17/93 12:00:00 AM DIRECTORY 201: new 0 11/27/99 01:58:00 PM SYMBOLIC-LINK 201: pub 0 11/07/00 07:46:00 PM DIRECTORY 201: usr 0 08/30/93 12:00:00 AM DIRECTORY 201: welcome.msg 312 08/01/94 12:00:00 AM FILE Note that the year is off by one for both "incoming" and "new." Note also that it only happens for the current date, 2000-11-27 here because "pub" has the same time format but mozilla gets the right year. BTW, 4.76 has the exact same problem so mozilla may have inherited an ancient bug.

I see what's happening. The server is speaking UTC, which seems eminently reasonable, but mozilla is speaking local time. In mozilla/netwerk/streamconv/converters/nsFTPDirListingConv.cpp, nsFTPDirListingConv::ConvertUNIXDate compares the server date with the current local time. Since I'm on Eastern time, mozilla thinks a recent date in the future. Note that users in Europe and Aisa will never see this bug while users in Hawaii will see it fro about half a day. I can find no way to determine if a server is talking UTC or not, so maybe mozilla should test against both local time and UTC. Of course, it would have to switch the test order depending on whether the current offset is positive or negative. Maybe it should just test days, not hours and minutes. Maybe it shouldn't bother at all.

ftp bugs to component:ftp

qa to me.

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

reassigning to bbaetz@cs.mcgill.ca.

Hmm. I may have fixed this in bug 78148. Lets wait for that to land, and then recheck.

+verifyme, testcase - I will check.

Not fixed in a 10-05-21 nightly. This bug is about providing correct data not about displaying data. Simple demonstration, if you run Linux: 1) create a new file in the anonymous ftp directory. 2) make sure your ftp server returns times in UTC, wu-ftpd does it by default, ProFTPD has an option. 3) set your local system time to zone time zone in the western hemishpere. 3) point mozilla at your ftp server and note that the file you just created appears to be a year old.

See bug 106114. We now don't do timezone conversion, so this should be fixed. The fact that we can't know sucks, I'll admit, but I cna't do much about it. See that bug for discussion. There is code to deal with this, and a quick glance doesn't show anything wrong. If its not fixed, I'll look into it.

If an 11-22-08 nightly is supposedly fixed, then no this isn't fixed. Bug 106114 seems to be about proper displaying but that won't help with bad data, which is what this bug is about. Let's try this again. The ls -l Unix listing format does *not* include a year if the date is less than 6 months ago. Mozilla attempts to be clever by temporarily assuming the current year. If the assumed date is older than now moziila accepts it. If the date is in the future mozilla assumes that the year is wrong and subtracts 1. The problem is that time zones make it possible for a time to appear to be a few hours into the future. Mozilla gets this case wrong. The current code is a crock. Mozilla should just convert times into integers (I know there are PR_* finctions to do that) and compare them rather than all this comparing monts and days, etc. If the proposed time is < now then accept it. If the proposed time > now + a fudge factor then subtract 1 from the year.

The problem is that if we're not given a year (which we aren't) AND we don't know the remote timezone (which we don't), then the answer will be ambiguous. In your example, what if the file had been created (1 year-1 hour) ago, and the remote server's timezone is the same as ours? How do we separate that case from your case? We have to get one of them wrong[1] Converting a time into seconds-since-the-epoch and comparing, vs comparing and then converting to a time_t makes no difference - we have to consider a fudge factor somewhere. [1] OK, techincally on Feb 29th, then we can know which year it must have been modified in. I'm not going to add code for that, as it doesn't help the other 99.9% of the time.

The problem seems to be that Mozilla doesn't have enough of a fudge factor, or doesn't have one at all. The one-hour fudge factor used by "ls" isn't enough when dealing with multiple time zones and systems whose clock might be off; I would recommend using a 1-month fudge factor forward.

Well, currently we don't have nay fudge factor. One month seems a bit too much, though - I don't think we need to deal with ftp servers which are that broken. 1-2 days seesm reasonable, though.

You need at least 26 hours. The server could be displaying UTC+13 local time and you could be in UTC-13. Yes, the time zones exist. Two days is probably reasonable although I wouldn't object to a longer interval.

Missed 0.9.7, ->0.9.9

I tried this a couple of months ago, but there were quite a few edge cases. -> 1.0

only nsbeta1+ bugs can have milestones, resetting to ---

back to 1.0

no time, -> 1.0.1

Is there anything wrong with just displaying the literal time presented by the server? If you don't know where in the world it is (and there is no way to tell), I don't understand the tangible benefit of doing time conversion.

Can confirm this bug on 1.0 rc3 on sparc solaris. OS is not restricted to Linux.

Mozilla 1.0 still has this bug. A convention used by many ftp servers is to return date and time (with no year) if the date is within plus or minus six months from current, but to return the year instead of the time in the field if the file is older than that. The reason is that a single field is allowed for either year or time but not both, so it can display the file time or the file year but not both. Mozilla seems to interpret these files as a year "backwards" from the current date instead of within a +/- 6 month sliding window. This is partcularly disconcerting when dealing with recent files uploaded to an FTP server which is "ahead" of you in the time zones, or even across the International Date Line. Mozilla should be fixed to use a sliding +/- 6 month "year" window when displaying the date of file listings that return a time instead of a year. Quick testcase: Manually set the date to one day ahead on an FTP server. Access the ftp server and list the file. It will show as being one year older than it is. Wait one day (or set the file date back to today) and it will display correctly. Alternatively, set the local system date/time to past/future to duplicate the symptom.

I have no time to work on mozilla at the moment, so dougt is taking over FTP open ftp bugs -> him

when we move to a new list parser, this bug should go away.

Fixed by 95590

Marking this fixed per comments above (fix for bug 95590)

tenthumbs, can you give us an update? You should be able to compare mozilla 1.1 and 1.2a, if I remember this correctly.

Mozilla now displays what the server sent so, yes, I think this bug is fixed.

VERIFIED/fixed, per contributor. If you have a public URL, please add it to the field.