[jira] [Commented] (HTTPCLIENT-2319) DateUtils.parseStandardDate() throws exception instead of returning null

2024-02-23 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820155#comment-17820155
 ] 

ASF subversion and git services commented on HTTPCLIENT-2319:
-

Commit f2b9a374d817ee630a2efe706546ba4f1e5a5ac4 in httpcomponents-client's 
branch refs/heads/master from Arturo Bernal
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=f2b9a374d ]

HTTPCLIENT-2319  / Updated the parseDate method to solely catch 
DateTimeException, streamlining error handling for date parsing and conversion. 
This change ensures comprehensive management of parsing issues, including those 
due to absent time-zone information, aligning with our documentation that the 
method should return null when conversion to Instant is not feasible. (#551)



> DateUtils.parseStandardDate() throws exception instead of returning null
> 
>
> Key: HTTPCLIENT-2319
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2319
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 5.3.1
>Reporter: Bernd Watermann
>Priority: Minor
>
> The following line of code
> {code:java}
> org.apache.hc.client5.http.utils.DateUtils.parseStandardDate("Thu Feb 22 
> 17:20:18 2024");{code}
> throws an exception with the following stack trace:
> {noformat}
> java.time.DateTimeException: Unable to obtain Instant from TemporalAccessor: 
> {},ISO resolved to 2024-02-22T17:20:18 of type java.time.format.Parsed
>     at java.base/java.time.Instant.from(Instant.java:380)
>     at 
> org.apache.hc.client5.http.utils.DateUtils.parseDate(DateUtils.java:165)
>     at 
> org.apache.hc.client5.http.utils.DateUtils.parseStandardDate(DateUtils.java:183){noformat}
> The documentation for parseStandardDate(), however, says:
> ??Returns: the parsed instant or null if input could not be parsed??
> Throwing an exception does not seem to conform to that spec.
> Note that I don't care (at present) if the given string should actually be 
> parseable or not. The primary issue is error handling and the fact that any 
> error should lead to a null result and not to an exception being thrown.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org



[jira] [Commented] (HTTPCLIENT-2319) DateUtils.parseStandardDate() throws exception instead of returning null

2024-02-23 Thread Oleg Kalnichevski (Jira)


[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820017#comment-17820017
 ] 

Oleg Kalnichevski commented on HTTPCLIENT-2319:
---

[~bwatermann] You are welcome to propose a fix by raising a PR at GitHub.

Oleg

> DateUtils.parseStandardDate() throws exception instead of returning null
> 
>
> Key: HTTPCLIENT-2319
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2319
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 5.3.1
>Reporter: Bernd Watermann
>Priority: Minor
>
> The following line of code
> {code:java}
> org.apache.hc.client5.http.utils.DateUtils.parseStandardDate("Thu Feb 22 
> 17:20:18 2024");{code}
> throws an exception with the following stack trace:
> {noformat}
> java.time.DateTimeException: Unable to obtain Instant from TemporalAccessor: 
> {},ISO resolved to 2024-02-22T17:20:18 of type java.time.format.Parsed
>     at java.base/java.time.Instant.from(Instant.java:380)
>     at 
> org.apache.hc.client5.http.utils.DateUtils.parseDate(DateUtils.java:165)
>     at 
> org.apache.hc.client5.http.utils.DateUtils.parseStandardDate(DateUtils.java:183){noformat}
> The documentation for parseStandardDate(), however, says:
> ??Returns: the parsed instant or null if input could not be parsed??
> Throwing an exception does not seem to conform to that spec.
> Note that I don't care (at present) if the given string should actually be 
> parseable or not. The primary issue is error handling and the fact that any 
> error should lead to a null result and not to an exception being thrown.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org