While wrestling with automated FTP jobs at work, thanks to a colleague I’ve discovered a cute little buglet when Windows talks to FTP servers using the Unix standards (which includes IIS by default). Actually it’s not so much a bug, it’s more of an issue of a supposedly user-friendly way of showing file dates still being used even when the “user” is another machine.

It goes like this… let’s say the Unix FTP server is 1 minute faster than the Windows client one, and the file is brand spanking new, just placed there. It’s 10am, and your Windows client goes looking for a file.

Windows says “What time was this file dropped?” Unix, being the kind of laid-back casual user-friendly operating system that it is, abbreviates its answer to exclude the year, and replies “Nov 4 10:01”.

Windows sees this, and the logic says “Right now it’s only 10:00am. This file can’t be from the future. I’ll assume it’s from last year.”

Evidently this can happen if the Unix server is a second or many minutes ahead. It may be further complicated if they’re running on different timezones, GMT vs AEST etc.

The solution is probably down to your individual circumstances. For us, we know we’d never be getting files that are a year old, so we can easily code around it. Ultimately though, surely something should be changed so that the client can get the full picture, not an abbreviated form of the file date/time.

• Same behaviour shown in IE
• Under some circumstances it’ll show a later year instead
• Other FTP products have variations on this problem too
• Heaps more reports in Google Groups, too.