This commit in PR #124 breaks FileUtils with new Java 8 datetime APIs:
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.