You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "dangerOp (JIRA)" <ji...@apache.org> on 2007/04/28 02:22:15 UTC
[jira] Created: (NET-159) FTPFile.getTimestamp() is off by one year
FTPFile.getTimestamp() is off by one year
-----------------------------------------
Key: NET-159
URL: https://issues.apache.org/jira/browse/NET-159
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4
Environment: winxp, jdk 1.5
Reporter: dangerOp
Priority: Minor
The Calendar object returned by FTPFile.getTimestamp seems to be short by one year.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (NET-159) FTPFile.getTimestamp() is off by one
year
Posted by "Julien Aymé (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501952 ]
Julien Aymé commented on NET-159:
---------------------------------
Hi Rory,
1. I may miss something on how a FTP server works, but it seems to me that the date returned in the file entries are always given from the GMT timezone. If so, the best way to correct it would be to compare the date given to the current date in the GMT timezone:
Instead of setting the Calendar timezone to the server timezone, I think we should set the Calendar timezone to GMT.
(in FTPTimestampParserImpl#parseTimestamp(String)).
2. I think the rollback behaviour should be disabled only if the date given is not more than one day ahead of the current date (since any timezone difference would be less than 24hours), and let the dates which are more than one day ahead be rolled back. By doing so, the date given by getTimestamp would be far more reliable:
Indeed, if I disable the Rollback behaviour, on the 1st January of any year, all my files would have their timestamps in the future :-)
Julien
> FTPFile.getTimestamp() is off by one year
> -----------------------------------------
>
> Key: NET-159
> URL: https://issues.apache.org/jira/browse/NET-159
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: winxp, jdk 1.5
> Reporter: dangerOp
> Priority: Minor
> Fix For: 2.0
>
>
> The Calendar object returned by FTPFile.getTimestamp seems to be short by one year.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Closed: (NET-159) FTPFile.getTimestamp() is off by one year
Posted by "Rory Winston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rory Winston closed NET-159.
----------------------------
Resolution: Fixed
Fix Version/s: 2.0
Added a method to disable the default rollback behaviour.
> FTPFile.getTimestamp() is off by one year
> -----------------------------------------
>
> Key: NET-159
> URL: https://issues.apache.org/jira/browse/NET-159
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: winxp, jdk 1.5
> Reporter: dangerOp
> Priority: Minor
> Fix For: 2.0
>
>
> The Calendar object returned by FTPFile.getTimestamp seems to be short by one year.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (NET-159) FTPFile.getTimestamp() is off by one
year
Posted by "Julien Aymé (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501954 ]
Julien Aymé commented on NET-159:
---------------------------------
PS: I did not find the method FTPClient#setDateRollbackPermitted(boolean) and I just updated from the trunk.
Does it correspond to the FTPConfig#setLenientFutureDates'boolean) ??
> FTPFile.getTimestamp() is off by one year
> -----------------------------------------
>
> Key: NET-159
> URL: https://issues.apache.org/jira/browse/NET-159
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: winxp, jdk 1.5
> Reporter: dangerOp
> Priority: Minor
> Fix For: 2.0
>
>
> The Calendar object returned by FTPFile.getTimestamp seems to be short by one year.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (NET-159) FTPFile.getTimestamp() is off by one
year
Posted by "Rory Winston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501047 ]
Rory Winston commented on NET-159:
----------------------------------
Hi guys
Thanks for the comments. I have analysed the issue, and here are my conclusions:
1. The synopsis you guys have given of the root cause of this issue is correct. If the date fits the recent date format, and the server timestamp > local timestamp, excluding any explicitly specified drift due to timezone differentials, then this problem will occur.
2. FTPClient has no way of knowing when it is and when it is not correct to roll back the date. The default bahviour is to always roll back.
I have added a method to FTPClient (setDateRollbackPermitted(boolean)). Call this method with value of "false" to explicitly disallow this behaviour. This should fix what you are seeing. I am marking this as fixed and doing a checkin. If any of you guys would like to check out the source and try my patch, you are most welcome.
As usual, any problems, let me know.
> FTPFile.getTimestamp() is off by one year
> -----------------------------------------
>
> Key: NET-159
> URL: https://issues.apache.org/jira/browse/NET-159
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: winxp, jdk 1.5
> Reporter: dangerOp
> Priority: Minor
> Fix For: 2.0
>
>
> The Calendar object returned by FTPFile.getTimestamp seems to be short by one year.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (NET-159) FTPFile.getTimestamp() is off by one
year
Posted by "Divyesh Patel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500796 ]
Divyesh Patel commented on NET-159:
-----------------------------------
Hi Julien,
Thank you for your early response.
The ftp server I am dealing with is not in my control; I have asked for more
information on it.
I do get a note in the startup message that they are using "X2 WS_FTP Server
5.0.5 (3295908506)".
I downloaded an evaluation copy of the "WS FTP" server and was able to
reproduce the year problem on my local network. I did not change any
configuration on the FTP server (left the default installation configuration
set by WS FTP). So the answer to your second question about specifying a
Date format in a FTPConfig would be "No".
I installed WS FTP on a server with a FAT32 disk; running Windows 2000 SP4.
The dir listing on the server does not return the year information for files
created in the current year:
And being on the local network, the server and JVM are in the same timezone.
However, it appears that the FTP server is reporting the UT time, which is
ahead of the local time by 6 hrs.
For debugging, I played around with the time on the server and touching the
test file - and indeed the year is reported as the previous year if the time
on the file timestamp is in the future compared to time of the client
computer.
Enabling the option to list file time in local time helped the issue. So did
setting the timezoneid for the FTP server that is not under my control.
However, this does mean that the year would be off by one if the Server time
is ahead of the actual time by a few minutes. Isn't it possible to assume
that the year on the file is the current year (based on the timezone of the
server - so the year is not skewed around new year's or for recent files) at
the server location; if the year is not included in the listing?
For now, my issue is resolved, so thank you very much for your help.
Please let me know if you need more information.
thanks,
Divyesh
> FTPFile.getTimestamp() is off by one year
> -----------------------------------------
>
> Key: NET-159
> URL: https://issues.apache.org/jira/browse/NET-159
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: winxp, jdk 1.5
> Reporter: dangerOp
> Priority: Minor
>
> The Calendar object returned by FTPFile.getTimestamp seems to be short by one year.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (NET-159) FTPFile.getTimestamp() is off by one
year
Posted by "Julien Aymé (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500675 ]
Julien Aymé commented on NET-159:
---------------------------------
Hello Divyesh,
Could you please give more informations about your issue, such as:
- what is the type of the FTP server from which the file was retrived? (Unix, NTFS, Enterprise Unix, ...) (the aim is to find out which FileEntryParser is used)
- do you specify your own Date format in a FTPConfig ?
After a quick source lookup, I found a possible scenario which would trigger the problem:
When a file entry (String) is parsed into a FTPFile,
the FTPFile timestamp is constructed by parsing the corresponding parts of the entry.
If the date being parsed does not contain year informations, the Calendar object being constructed has its year set to the current* year, and if this Calendar is after the current* time, its year is reduced by one.
Here, current* is the current time of the JVM in which the code executes.
So, if the retrived file is recent enough, and if the file's server is in a different timezone of the JVM's timezone, it is possible that the date in the file entry is after the current date (even if it does contain year informations by the way), and thus, producing the behaviour described above.
I hope this was not too much confusing and helped a litte,
Regards,
Julien
> FTPFile.getTimestamp() is off by one year
> -----------------------------------------
>
> Key: NET-159
> URL: https://issues.apache.org/jira/browse/NET-159
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: winxp, jdk 1.5
> Reporter: dangerOp
> Priority: Minor
>
> The Calendar object returned by FTPFile.getTimestamp seems to be short by one year.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (NET-159) FTPFile.getTimestamp() is off by one
year
Posted by "Divyesh Patel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500518 ]
Divyesh Patel commented on NET-159:
-----------------------------------
I have the same issue, any update on a fix would be welcome.
-thanks.
> FTPFile.getTimestamp() is off by one year
> -----------------------------------------
>
> Key: NET-159
> URL: https://issues.apache.org/jira/browse/NET-159
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: winxp, jdk 1.5
> Reporter: dangerOp
> Priority: Minor
>
> The Calendar object returned by FTPFile.getTimestamp seems to be short by one year.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (NET-159) FTPFile.getTimestamp() is off by one
year
Posted by "Julien Aymé (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500681 ]
Julien Aymé commented on NET-159:
---------------------------------
PS: If I am missing something about time returned by the FTP servers, I'd be glad to be teached :-)
> FTPFile.getTimestamp() is off by one year
> -----------------------------------------
>
> Key: NET-159
> URL: https://issues.apache.org/jira/browse/NET-159
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: winxp, jdk 1.5
> Reporter: dangerOp
> Priority: Minor
>
> The Calendar object returned by FTPFile.getTimestamp seems to be short by one year.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (NET-159) FTPFile.getTimestamp() is off by one
year
Posted by "Rory Winston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502143 ]
Rory Winston commented on NET-159:
----------------------------------
Hi Julien
1. We cant make the assumption that remote timestamps will be GMT, they can in fact be an arbitrary timezone.
2. We may need to tweak the logic, however, I think your example is incorrect here. Disabling rollback on e.g. 1-Jan-2007 should display all recent format files correctly. Unless you are talking about files created on, for example, December 31st, and displayed using a recent file format, in which case, I think there may be a possibility that these files could be marked with the incorrect year. So maybe there might be a case for some sort of change along the lines you have mentioned - maybe something like:
if (remote is recent_date_format and remote.time > now)
if (now.day == remote.day && now.month == remote.month) then dont rollback
else rollback
3. The changes are on the 2.0 branch:
http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/?sortby=date
> FTPFile.getTimestamp() is off by one year
> -----------------------------------------
>
> Key: NET-159
> URL: https://issues.apache.org/jira/browse/NET-159
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: winxp, jdk 1.5
> Reporter: dangerOp
> Priority: Minor
> Fix For: 2.0
>
>
> The Calendar object returned by FTPFile.getTimestamp seems to be short by one year.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org