[
https://issues.apache.org/jira/browse/IO-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated IO-689:
-----------------------------
Description:
This commit in PR #124 breaks FileUtils with new Java 8 datetime APIs:
https://github.com/apache/commons-io/pull/124/commits/2eb549873470844c88681e92c64631f796002020
Because of this I had to put all of the methods to the list of blacklisted APIs
in Apache Lucene / Solr. The reason for this change is that now all depend on
local datetime, there's no way to pass an Instant with a UNIX timestamp through
the API without it being corrupted due to forwards/backwards transformation.
Background: During DST changes the same local date time exists two times (in
autumn, you have in most countries two time the 2:30am time, once before and
once after the DST change - because time is rolled back).
With the above commit you first convert an Instant (which is by definition just
a UNIX timestamp and can be converted as-is to a long) to a local Datetime and
then back to an Instant. By this forward/backward transformation you get off by
an hour during that one hour in autumn, when DST switches back to standard time.
Please revert this commit and release a bugfix.
There is no reason to convert an Instant to local and back, the arguments in
the PR are plain wrong. Instants are timezoneless and are identical to UNIX
timestamps.
This commit breaks all new methods, because at the end all new methods go
through the "Instant" path which does the faulty transformation.
was:
This commit in PR #124 breaks FileUtils with new Java 8 datetime APIs:
https://github.com/apache/commons-io/pull/124/commits/2eb549873470844c88681e92c64631f796002020
Because of this I had to put all of the methods to the list of blacklisted APIs
in Apache Lucene / Solr. The reason for this change is that now all depend on
local datetime, there's no way to pass an Instant with a UNIX timestamp through
the API without it being corrupted due to forwards/backwards transformation.
Background: During DST changes the same local date time exists two times (in
autumn, you have in most countries two time the 2:30am time, once before and
once after the DST change - because time is rolled back).
With the above commit you first convert an Instant (which is by definition just
a UNIX timestamp and can be converted as-is to a long) to a local Datetime and
then back to an Instant. By this forward/backward transformation you get off by
an hour during that one hour in autumn, when DST switches back to standard time.
Please revert this commit and release a bugfix.
There is no reason to convert an Instant to local and back, the arguments in
the PR are plain wrong. Instants are timezoneless and are identical to UNIX
timestamps.
> All new FileUtils method with Java 8 time break on DST change
> -------------------------------------------------------------
>
> Key: IO-689
> URL: https://issues.apache.org/jira/browse/IO-689
> Project: Commons IO
> Issue Type: Task
> Components: Utilities
> Affects Versions: 2.8.0
> Reporter: Uwe Schindler
> Priority: Major
>
> This commit in PR #124 breaks FileUtils with new Java 8 datetime APIs:
> https://github.com/apache/commons-io/pull/124/commits/2eb549873470844c88681e92c64631f796002020
> Because of this I had to put all of the methods to the list of blacklisted
> APIs in Apache Lucene / Solr. The reason for this change is that now all
> depend on local datetime, there's no way to pass an Instant with a UNIX
> timestamp through the API without it being corrupted due to
> forwards/backwards transformation.
> Background: During DST changes the same local date time exists two times (in
> autumn, you have in most countries two time the 2:30am time, once before and
> once after the DST change - because time is rolled back).
> With the above commit you first convert an Instant (which is by definition
> just a UNIX timestamp and can be converted as-is to a long) to a local
> Datetime and then back to an Instant. By this forward/backward transformation
> you get off by an hour during that one hour in autumn, when DST switches back
> to standard time.
> Please revert this commit and release a bugfix.
> There is no reason to convert an Instant to local and back, the arguments in
> the PR are plain wrong. Instants are timezoneless and are identical to UNIX
> timestamps.
> This commit breaks all new methods, because at the end all new methods go
> through the "Instant" path which does the faulty transformation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
