mr slim
This was addressed recently in the Users Helping Users forum in the following topic:
https://www.smartftp.com/forums/viewtopic.ph ... highlight=
As it's something of a problem, I think reporting it as a bug is appropriate.
More detail is there, but to sum it up, on servers that don't provide a year in the raw listing, SmartFTP apparently "guesses" based on the time relative to the current time.
To quote Mat from that thread:
>For dates without a year in the listing the following rule applies:
>
>If date in listing is in the future: Year = Current Year - 1
>There's some +- here (about 6 hours) because the FTP server may be in a different time zone.
>
>If date is in the past: Year = Current Year
>
>That's the reason the year is not always correct. If you have a better idea how to solve this "missing year in date" problem pelase let me know.
My server's timezone is GMT. I'm PST, so there's an 8 hour difference. That means that between 16:00 and 00:00 my time, I see all newly uploaded files to my server having the proper timestamp GMT EXCEPT that the year is 2002 instead of 2003.
I understand the dilemma, but literally every other ftp client I've tried this on is able to display the year correctly. Many of these clients are considerably less sophisticated than SmartFTP. If I display the contents of the directory in my browser window, the year is correct there, too.
My host says that eventually, they'll output the year, but they don't know when.
There must be some way to address this since other programs do. Perhaps test more specifically for the future date. If the date of the file is more than 24 hours into the future, then use your current formula, otherwise, give the file on the server the current year is one simple thing that comes to mind that has its flaws, but would be more accurate than the current approach.
Otherwise, I very much appreciate the good work and enjoy using SmartFTP.
BTW, I'm not including system info because the issue was already confirmed in the post indicated above. That information is there if you'd like to see it.
https://www.smartftp.com/forums/viewtopic.ph ... highlight=
As it's something of a problem, I think reporting it as a bug is appropriate.
More detail is there, but to sum it up, on servers that don't provide a year in the raw listing, SmartFTP apparently "guesses" based on the time relative to the current time.
To quote Mat from that thread:
>For dates without a year in the listing the following rule applies:
>
>If date in listing is in the future: Year = Current Year - 1
>There's some +- here (about 6 hours) because the FTP server may be in a different time zone.
>
>If date is in the past: Year = Current Year
>
>That's the reason the year is not always correct. If you have a better idea how to solve this "missing year in date" problem pelase let me know.
My server's timezone is GMT. I'm PST, so there's an 8 hour difference. That means that between 16:00 and 00:00 my time, I see all newly uploaded files to my server having the proper timestamp GMT EXCEPT that the year is 2002 instead of 2003.
I understand the dilemma, but literally every other ftp client I've tried this on is able to display the year correctly. Many of these clients are considerably less sophisticated than SmartFTP. If I display the contents of the directory in my browser window, the year is correct there, too.
My host says that eventually, they'll output the year, but they don't know when.
There must be some way to address this since other programs do. Perhaps test more specifically for the future date. If the date of the file is more than 24 hours into the future, then use your current formula, otherwise, give the file on the server the current year is one simple thing that comes to mind that has its flaws, but would be more accurate than the current approach.
Otherwise, I very much appreciate the good work and enjoy using SmartFTP.
BTW, I'm not including system info because the issue was already confirmed in the post indicated above. That information is there if you'd like to see it.
