Closed Bug 30994 Opened 24 years ago Closed 24 years ago

FTP listing does not show "last modified"

Categories

(Core :: Internationalization, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: Sebastian, Assigned: nhottanscp)

References

()

Details

(Keywords: intl, Whiteboard: [nsbeta3-][mozilla1.0] fixed in the trunk[rtm-])

Attachments

(3 files)

Going to the Mozilla ftp site shows Name and Size of the file directory, but the
Last Modified column stays empty. Resizing the columns works but will reveal
nothing new. Sometimes the column will switch from grey to white or the other
way round.
This prevents me from seeing of which date the newest Mozilla nightlies are.

Win95 build 03/05 (seen it for quite long now)
(BTW which is the right FTP layout related component?)
the correct component is Networking
(http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser)

however, on 3/5, cannot reproduce on win98.  try a reinstalling moz
If it's a display problem then it could be XPToolkit Trees.
Giving to hyatt, XP toolkit-trees per asadotzler's comment
Assignee: cbegle → hyatt
Damm it, forgot to change component as well, sorry.
Component: Browser-General → XP Toolkit/Widgets: Trees
bftzl
Assignee: hyatt → waterson
Status: NEW → ASSIGNED
Target Milestone: --- → M16
Problem still exists with build 03/24.
Correction: colums will not just turn to grey or white. The last clicked column
will become grey, which is perfectly right. It just doesn't has any stuff in the
size column, even after resizing.
Reinstalling didn't help.
jud: does FTP reliably produce this information? If so, can we add it to the
http-index stream that FTP generates? I can do something similar for the file
stream.
ftp is already pumping this data over. it used to work. something must be wrong 
on the display/xul side.
Hmm. This WORKSFORME.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Reopening, as I still see it and at least two other people see it as well on
windows with the current nightly as of 06/08
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This could be some problems with international date formats. All the "problem
cases" are using German Windows versions.
This has never worked for me. Note that it works on Linux, doesn't work on win32
for me.
Could it be that ftp on win32/international has different file date/time output?
Note that Sebastian Späth (reporter) and I have win32/german versions, while
Doron Rosenberg ("worksforme") has win32/english, what, I assume, waterson also
is running.
change component to I18n per comments. erik, any clue who the right person to
track this down would be? appears to be a problem with date-time formats on
non-US windows.
Component: XP Toolkit/Widgets: Trees → Internationalization
Target Milestone: M16 → Future
Naoki, please take a look at this date/time format issue.
It is working fine on my WinNT Japanese. This could be Win95 specific.
Teruko, could you try this on Win95 Japanese?
I see this problem on WIN98 SE RUS.
I have been seeing this problem on WinNT4 German for a while now.
Not reproducible on Fr Win NT 4 (we do not have DE Win NT 4 installed).
We cannot reproduce, can anybody attach a screen shot of the problem?
I attached a screenshot. The dates are just not showing at all. 
BTW: Shot was taken with M16, but the problem is still occuring in recent 
nightlies.
Could you specify the system info (WinNT DE)?
It is German Win95b as I reported in the bug, using nightly mozillas.
Does this only happen in ftp listing? Dates in bookmark and mail/news display 
correctly?
Yup, it happens only in FTP-listings. Mail/News and bookmarks display the dates 
correct in the localized DD.MM.YY format
This is reproducible with US WinNT. 
Go to ControlPanel and open Regional Settings then Select "German (Standard)".

When I debug, I see international date format returns a correct date string 
(e.g. "21.06.00 17:38") in nsFTPDirListingConv::DigestBufferLines.
Assignee: waterson → rjc
Status: REOPENED → NEW
-> rjc
Here's what I'm seeing (on WinNT) after setting my region to be "German 
(Standard)":

When FTPing to the URL given (at the top of this bug report), we get dates back 
such as "21.06.00 17:38" which we then pass into a call to
    PR_ParseTimeString()
which reports an error back.

I guess NSPR doesn't enjoy dot notation in date strings.

As a reference, the call is at:
    mozilla/xpfe/components/directory/nsDirectoryViewer.cpp
in  nsHTTPIndexParser::ParseDate()   [around line # 818]


nhotta, do you have if there is a better way of parsing strings into date/time 
values?
Assignee: rjc → nhotta
I think PR_ParseTimeString does not support international string as input.
It is possible to get a date string and a time string separately so no need to 
parse the string later.
When calling FormatPRExplodedTime, 
specify kDateFormatNone to nsDateFormatSelector to get a time only string, 
specify kTimeFormatNone to nsTimeFormatSelector to get a date only string.

Assignee: nhotta → rjc
updating QA Contact
QA Contact: asa → teruko
Nominating for nsbeta3.
Keywords: nsbeta3
triage team:
nsbeta3-
Whiteboard: [nsbeta3-]
Keywords: mozilla1.0
Nominating for Mozilla 1.0, but forgot whether to set status or keyword to 
[mozilla1.0]. Mmmh, I guess status is the right one...
Keywords: mozilla1.0
Whiteboard: [nsbeta3-] → [nsbeta3-][mozilla1.0]
Suggest platform=all since I see this also with Linux (Mozilla nightly
2000-10-09-18). LANG=de_DE.ISO-8859-1.
If I unset LANG I see more than three (ups) files and see the last modified
date! This is really a I18N bug! But it is not restricted to Windows!
Setting platform to all, seen with at least Win and Linux. I propose to not 
"future" this one... (adding RTM)
OS: Windows 95 → All
Hardware: PC → All
Whiteboard: [nsbeta3-][mozilla1.0] → [nsbeta3-][mozilla1.0] [RTM]
Reassigning to ftang... Frank, this was the cause of FTP bug # 51446 (when dates 
have dots in them) and NSPR failing on parsing the string.  With bug # 51446 now 
fixed, it will display FTP items even if it can't parse the date/time string, but 
it would be really nice to be able to display them even if they have dots in 
them...

As a reference, the call is at:
    mozilla/xpfe/components/directory/nsDirectoryViewer.cpp
in  nsHTTPIndexParser::ParseDate()   [around line # 845 these days, I believe]
Assignee: rjc → ftang
> it would be really nice to be able to display them [date/time] even if they
> have dots in them...
Note: The ISO date format contains '-' (such as 2000-10-08) I don't know whether
it is used anywhere, but it should taken into account that something like this
exists.
Moving rtm from status whiteboard to keywords. I'm leaving mozilla1.0 in
whiteboard until there is a decision about RTM keyword.
(mozilla0.6, mozilla0.9, mozilla1.0 etc. are defined as keywords, Sebastian.
Just look into the keyword list :-> )
Keywords: rtm
Whiteboard: [nsbeta3-][mozilla1.0] [RTM] → [nsbeta3-][mozilla1.0]
The problem is the following code using the locale senstive date/time formater 
function to generate the date. However, the 
xpfe/components/directory/nsDirectoryViewer.cpp rjc wrote will parse the 
date/time using the NSPR date time parsing function  PR_ParseTimeString which 
expect non-locale sensitve format.
netwerk/streamconv/converters/nsFTPDirListingConv.cpp#875

875         rv = mDateTimeFormat->FormatPRExplodedTime(mLocale, 
kDateFormatShort, kTimeFormatNoSeconds, &thisEntry->mMDTM, lDate);
876         if (NS_FAILED(rv)) {
877             NS_DELETEXPCOM(thisEntry);
878             return nsnull;
879         }
880 
to fix this , we should replace  mDateTimeFormat->FormatPRExplodedTime to a 
non-locale senstive version which the  PR_ParseTimeString can handle later. 

I guess we should use PR_FormatTimeUSEnglish here and I believe rjc's code later 
will use the locale sensitive format function to regenerate the data/time format 
according the the locale correctly again later.

I am not sure what format string we should use here. 
wtc, any suggestion ?


nhotta, can you work on this ? I don't think we can fix this for RTM, but it 
will be nice if we can fix this right after.
Assignee: ftang → nhotta
add wtc and gagan to the list.
Status: NEW → ASSIGNED
I do understand all in US use US regiaonal settings, but can you think 
about other counties with users with own regional settings different from US?

They will not recieve a good product! It is not so hard to fix (how could I 
understand, but I'm not a programmer :((( ), so PLEASE, PLEASE DO IT FOR RTM!

With the patch, it shows "20.10.00 10:33:00" for German locale.
For US locale shows  "10/20/00 10:33:00" as before.
Rjc, could you review the patch?
I'm OK with this patch, but it has me wondering... should we use a 4-digit year 
instead of a 2-digit year?
Rjc, 2 digit format is done in RDF code (nxXULContentUtils.cpp), so that should 
be taken care separately from this patch.
Naoki, a couple of comments,
can you make lDate and nsAutoString.
also, why do we need theDate variable?
Can't we just do:
char * escapedDate = nsEscape(NS_ConvertUCS2ToAscii(lDate.GetUnicode()), ...);
?

PR_FormatTimeUSEnglish returns only ASCII, so we don't have to use lDate which 
is nsAutoString. And theDate variable is not needed either as you mentioned.
I will attach a new patch.
Adding mscott to cc.
this is the same patch as before =). I think you posted the wrong file =).
No, the new one does not have nsCAutoString theDate(buffer);
Ummm, it sure does:
!         nsCAutoString theDate;
! 	theDate.AssignWithConversion(lDate);
!         char *escapedDate = nsEscape(theDate.GetBuffer(), url_Path);

I don't see any difference between the last two patches.
My problem, the diff used "-c" instead of "-u", so he was looking at the old 
code. I got sr from mscott.
Whiteboard: [nsbeta3-][mozilla1.0] → [nsbeta3-][mozilla1.0] r=rjc,sr=msoctt
Whiteboard: [nsbeta3-][mozilla1.0] r=rjc,sr=msoctt → [nsbeta3-][mozilla1.0] fixed in the trunk
Target Milestone: Future → M21
nhotta, shouldn't some mozillaX.X target be used instead of Mxx notation?
(Target Milestone setting)
PR_FormatTime() and PR_FormatTimeUSEnglish() are deprecated
functions.  It would be better if you could write some code
to generate the date/time string in the appropriate format.
>PR_FormatTime() and PR_FormatTimeUSEnglish() are deprecated
functions.
wtc- what is the replacement function for them ?
Whiteboard: [nsbeta3-][mozilla1.0] fixed in the trunk → [nsbeta3-][mozilla1.0] fixed in the trunk[rtm-]
There are no replacement functions for PR_FormatTime
and PR_FormatTimeUSEnglish.  You will have to write
your own date/time formatting code.  The reason we
don't want to support these two functions is that
the date/time string format has to do with locales,
which have been out of the scope of NSPR.

Now, for backward compatibility reasons, we usually
continue to support most deprecated functions.  (I
guess I am being too honest.)  But in this case
I highly recommend that you write code to generate
the date/time string in the format suitable for your
application.
Well, as my original bug issue is fixed and the summary is a bit misleading 
about the remaining stuff, I suppose you close this one and open a new one for 
the deprecated PR_FormatTime and PR_FormatTimeUSEnglish issue.
I think this bug report is long enough anyway :-)
There is already international format interface, nsIDateTimeFormat.

For this FTP case, a date string is expected as in canonical form. I think nspr
should provide such functions (if the current functions are deprecated).
Otherwise, we should always use PRExplodedTime instead of passing around date in
string form. Or use whatever type FTP defines about date format.

Keywords: intl
This is fixed in the trunk, I think I forgot to mark it FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
verified fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: