Leap year issues in apache commons-net
I never encountered any real Y2K bugs in code I was involved in. Today, however, I ran into a nasty problem caused by date parsing in the apache commons-net library.
We have a project where files are being processed, xslt transformations are applied and so on. Some of these files have to be retrieved using FTP (I know...). We use the Apache commons-net 1.4.1 library for doing this.
Today, a number of files were not processed. I had to dive into the Apache code (Open Source is cool) to find the problem.
The method we are calling is this:
org.apache.commons.net.ftp.FTPClient.listFiles (String dir).
Following a long trail with engines and parsers, I discovered that the FTPFiles that are created get a Date that is obtained by parsing the date provided by the ftp server. The Unix ftp server returns the date in the format "MMM d HH:mm". No year info is supplied. This caused problems, of course, since Feb 29 is not a valid day in the default year 1970.
For those interested in the code: have a look at org.apache.commons.net.ftp.parser.FTPTimestampParserImpl.parseTimestamp(String s).
Fixing this is not too hard, but it is easier to manually change the date of the File back to Feb 28 23:59 
I feel like it's April fools' day. I am curious how many other people run into a similar leap year issue.
written on 29/02/2008 13:17
993 spam attempts blocked by mollom
Felt so hopeless looking for asnwres to my questions...until now.
Felt so hopeless looking for asnwres to my questions...until now.
It was dark when I woke. This is a ray of ssnuhine.
Your answer was just what I neeedd. It's made my day!
Your answer was just what I neeedd. It's made my day!
Very nice site!
Very nice site!