[jira] [Updated] (IO-689) All new FileUtils method with Java 8 time break on DST change

["Uwe Schindler (Jira)" <ji...@apache.org>]

     [ 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)