commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (NET-591) FTPFileStampParserImpl failing when parsing correctly formed datetimestring (daylight saving issue)
Date Wed, 06 Apr 2016 21:49:25 GMT

     [ https://issues.apache.org/jira/browse/NET-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

J updated NET-591:
------------------
    Description: 
In the class FTPTimeStampParserImpl,
the SimpleDateFormat hackFormatter
will throw an exception for certain datestrings, even though their SimpleDateFormat pattern
for the hackFormatter instance is correct ("MMM d HH:mm yyyy")
when in an environment that has daylight savings, like the environment reported in this bug
report.

For example:
Line 123:          
 parsed = hackFormatter.parse(timeStampStrPlusYear, pp);
where timeStampStrPlusyear = "Mar 27 02:02 2016"
will fail but 
 timeStampStrPlusyear = "Mar 27 03:02 2016"
would work.

Looking around I found two suggestions that might fix these kind of problems in the code.
The problem is according to http://blog.tier1app.com/2013/05/29/daylight-savings-time-problem-java/
that because of the daylight saving, the time 
02:02 doesn't exist in my timezone (thats true - timezone leap was 02:00 27th).

Setting the hackformatters lenient to true would make it work.
However I don't know if that's the right way for this project.


  was:
In the class FTPTimeStampParserImpl,
the SimpleDateFormat hackFormatter
will throw an exception for certain datestrings, even though their SimpleDateFormat pattern
for the hackFormatter instance is correct ("MMM d HH:mm yyyy")
when in an environment that has daylight savings, like the environment reported in this bug
report.

For example:
Line 123:          
 parsed = hackFormatter.parse(timeStampStrPlusYear, pp);
where timeStampStrPlusyear = "Mar 27 02:02 2016"
will fail but 
 timeStampStrPlusyear = "Mar 27 03:02 2016"
would work.

Looking around I found two suggestions that might fix these kind of problems in the code.

1) The default constructor of the Gregorian Calendar uses the local timezone of the machine.
Setting the GregorianCalendar(TimeZone) constructor and pass UTC into that should work, but
that would probally mean changing a lot of code.
2) Setting the hackformatters lenient to true will also make it work.

However I don't know what's the right way for this project, one of the above or another solution.



> FTPFileStampParserImpl failing when parsing correctly formed datetimestring (daylight
saving issue)
> ---------------------------------------------------------------------------------------------------
>
>                 Key: NET-591
>                 URL: https://issues.apache.org/jira/browse/NET-591
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>         Environment: locale: sv_SE
> timezone: "Europe/Stockholm"
> llinux/unix
>            Reporter: J
>
> In the class FTPTimeStampParserImpl,
> the SimpleDateFormat hackFormatter
> will throw an exception for certain datestrings, even though their SimpleDateFormat pattern
for the hackFormatter instance is correct ("MMM d HH:mm yyyy")
> when in an environment that has daylight savings, like the environment reported in this
bug report.
> For example:
> Line 123:          
>  parsed = hackFormatter.parse(timeStampStrPlusYear, pp);
> where timeStampStrPlusyear = "Mar 27 02:02 2016"
> will fail but 
>  timeStampStrPlusyear = "Mar 27 03:02 2016"
> would work.
> Looking around I found two suggestions that might fix these kind of problems in the code.
> The problem is according to http://blog.tier1app.com/2013/05/29/daylight-savings-time-problem-java/
that because of the daylight saving, the time 
> 02:02 doesn't exist in my timezone (thats true - timezone leap was 02:00 27th).
> Setting the hackformatters lenient to true would make it work.
> However I don't know if that's the right way for this project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message