Closed
Bug 30994
Opened 24 years ago
Closed 24 years ago
FTP listing does not show "last modified"
Categories
(Core :: Internationalization, defect, P3)
Core
Internationalization
Tracking
()
VERIFIED
FIXED
People
(Reporter: Sebastian, Assigned: nhottanscp)
References
()
Details
(Keywords: intl, Whiteboard: [nsbeta3-][mozilla1.0] fixed in the trunk[rtm-])
Attachments
(3 files)
29.27 KB,
image/png
|
Details | |
1.34 KB,
patch
|
Details | Diff | Splinter Review | |
1.35 KB,
patch
|
Details | Diff | Splinter Review |
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?)
Comment 1•24 years ago
|
||
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
Comment 2•24 years ago
|
||
If it's a display problem then it could be XPToolkit Trees.
Reporter | ||
Comment 3•24 years ago
|
||
Giving to hyatt, XP toolkit-trees per asadotzler's comment
Assignee: cbegle → hyatt
Reporter | ||
Comment 4•24 years ago
|
||
Damm it, forgot to change component as well, sorry.
Component: Browser-General → XP Toolkit/Widgets: Trees
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M16
Reporter | ||
Comment 6•24 years ago
|
||
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.
Comment 7•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
ftp is already pumping this data over. it used to work. something must be wrong on the display/xul side.
Comment 9•24 years ago
|
||
Hmm. This WORKSFORME.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 10•24 years ago
|
||
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 → ---
Reporter | ||
Comment 11•24 years ago
|
||
This could be some problems with international date formats. All the "problem cases" are using German Windows versions.
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
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
Comment 14•24 years ago
|
||
Naoki, please take a look at this date/time format issue.
Assignee | ||
Comment 15•24 years ago
|
||
It is working fine on my WinNT Japanese. This could be Win95 specific. Teruko, could you try this on Win95 Japanese?
Comment 16•24 years ago
|
||
I see this problem on WIN98 SE RUS.
Comment 17•24 years ago
|
||
I have been seeing this problem on WinNT4 German for a while now.
Assignee | ||
Comment 18•24 years ago
|
||
Not reproducible on Fr Win NT 4 (we do not have DE Win NT 4 installed).
Assignee | ||
Comment 19•24 years ago
|
||
We cannot reproduce, can anybody attach a screen shot of the problem?
Reporter | ||
Comment 20•24 years ago
|
||
Reporter | ||
Comment 21•24 years ago
|
||
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.
Assignee | ||
Comment 22•24 years ago
|
||
Could you specify the system info (WinNT DE)?
Reporter | ||
Comment 23•24 years ago
|
||
It is German Win95b as I reported in the bug, using nightly mozillas.
Assignee | ||
Comment 24•24 years ago
|
||
Does this only happen in ftp listing? Dates in bookmark and mail/news display correctly?
Reporter | ||
Comment 25•24 years ago
|
||
Yup, it happens only in FTP-listings. Mail/News and bookmarks display the dates correct in the localized DD.MM.YY format
Assignee | ||
Comment 26•24 years ago
|
||
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.
Updated•24 years ago
|
Assignee: waterson → rjc
Status: REOPENED → NEW
Comment 27•24 years ago
|
||
-> rjc
Comment 28•24 years ago
|
||
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
Assignee | ||
Comment 29•24 years ago
|
||
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
Reporter | ||
Updated•24 years ago
|
Keywords: mozilla1.0
Reporter | ||
Comment 33•24 years ago
|
||
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]
Comment 34•24 years ago
|
||
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!
Reporter | ||
Comment 35•24 years ago
|
||
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]
Comment 36•24 years ago
|
||
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
Comment 37•24 years ago
|
||
> 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.
Comment 38•24 years ago
|
||
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]
Comment 39•24 years ago
|
||
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
Comment 40•24 years ago
|
||
add wtc and gagan to the list.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 41•24 years ago
|
||
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!
Assignee | ||
Comment 42•24 years ago
|
||
Assignee | ||
Comment 43•24 years ago
|
||
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?
Comment 44•24 years ago
|
||
I'm OK with this patch, but it has me wondering... should we use a 4-digit year instead of a 2-digit year?
Assignee | ||
Comment 45•24 years ago
|
||
Rjc, 2 digit format is done in RDF code (nxXULContentUtils.cpp), so that should be taken care separately from this patch.
Comment 46•24 years ago
|
||
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()), ...); ?
Assignee | ||
Comment 47•24 years ago
|
||
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.
Assignee | ||
Comment 48•24 years ago
|
||
Assignee | ||
Comment 49•24 years ago
|
||
Adding mscott to cc.
Comment 50•24 years ago
|
||
this is the same patch as before =). I think you posted the wrong file =).
Assignee | ||
Comment 51•24 years ago
|
||
No, the new one does not have nsCAutoString theDate(buffer);
Comment 52•24 years ago
|
||
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.
Assignee | ||
Comment 53•24 years ago
|
||
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
Assignee | ||
Updated•24 years ago
|
Whiteboard: [nsbeta3-][mozilla1.0] r=rjc,sr=msoctt → [nsbeta3-][mozilla1.0] fixed in the trunk
Assignee | ||
Updated•24 years ago
|
Target Milestone: Future → M21
Comment 54•24 years ago
|
||
nhotta, shouldn't some mozillaX.X target be used instead of Mxx notation? (Target Milestone setting)
Comment 55•24 years ago
|
||
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.
Comment 56•24 years ago
|
||
>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-]
Comment 57•24 years ago
|
||
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.
Reporter | ||
Comment 58•24 years ago
|
||
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 :-)
Assignee | ||
Comment 59•24 years ago
|
||
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.
Assignee | ||
Comment 60•24 years ago
|
||
This is fixed in the trunk, I think I forgot to mark it FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•