Date parsing issues

Question

I like edtftpj very much, but I think some improvements could be made with respect to date parsing. IMHO it doesn't make much sense to use the client's system locale by default for parsing the server's date output. The remote host's locale should be used, and if that can't be found out, Locale.ENGLISH would be the second best choice. I, for example, live in Germany, but hardly any FTP server speaks German, even if located around the corner.

Presently, if the local and remote locales don't happen to correspond, calling dirDetails() causes the program to crash with a ParseException. I think this is too severe a punishment for an end user who has no influence on the program's behavior and knows nothing about the server's locale. A more user-friendly reaction to such situations could be:

1. If the programmer has ever explicitly called setLocale() on the the parser, throw an exception.
2. If not, don't throw. Instead, set the modification date to a significant value, like Date(0).

An alternative (which requires less refactoring) would be adding a method parserThrows(boolean) to FTPClient, which toggles between throwing and using Date(0).

Opinions?

- Bernd

Answer 1

Unfortunately there's no simple way to detect the FTP server's encoding.

Perhaps setting the default to ENGLISH is a good way to go.

I'm not so keen on Date(0) - I'd rather throw an exception if there's an error rather than return an incorrect result - forcing the user to work out what the proper locale is.

One idea that does occur to me is to try some common locales if a parse exception does occur - or perhaps look at the names of the months that are returned. If French or German names are returned, for example, it would be easy to set the locale appropriately.

Answer 2

I agree that finding out the locale in a reliable way would be most desirable.
However, I disagree with your notion of "error". Consider a program which lets the user enter a host name. You can't blame the programmer for not knowing which host the user chooses. In the present situation, even if the program isn't interested in modification dates, it has to prompt the user for the locale. The user will have to find out somehow (how?), and if he enteres an incorrect one, the program crashes. Would you really call that a user error? Or, to put it differently: Would you buy such a program?
The intermediate solution I proposed allows the programmer to write correct programs if dates play no role, or to keep the present behavior, according to his needs. I implemented this version for my own purposes and will stick tp it until the problem is solved in a more elegant way.

- Bernd