[
https://issues.apache.org/jira/browse/IO-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200693#comment-17200693
]
Alex Herbert commented on IO-689:
---------------------------------
This concerns for example the following method:
{code:java}
public static boolean isFileNewer(final File file, final Instant instant) {
Objects.requireNonNull(instant, "instant");
return isFileNewer(file,
instant.atZone(ZoneId.systemDefault()).toInstant().toEpochMilli());
}
{code}
Reading the javadoc {{Instant.atZone}} is equivalent to
{{ZonedDateTime.ofInstant(this, zone)}}. The javadoc for that states that:
{noformat}
"Calling toInstant() will return an instant equal to the one used here.
Converting an instant to a zoned date-time is simple as there is only one valid
offset for each instant."
{noformat}
Thus the following is documented to be a round trip to an equivalent Instant:
{code:java}
instant.atZone(ZoneId.systemDefault()).toInstant()
{code}
So IIUC the conversion to/from should have no effect.
I have tried to create a DateTimeZone on the time change for British Summer
Time and the instant from this can be offset by 1 hour and still passes a round
trip:
{code:java}
@Test
public void testIO689() {
// Daylight saving time in United Kingdom ends 02:00 on Sunday, 25 October,
2020
ZoneId bstZone = ZoneId.of("Europe/London");
ZonedDateTime date = ZonedDateTime.of(2020, 10, 25, 2, 0, 0, 0, bstZone);
Instant instant = date.toInstant();
Instant instant2 = instant.plus(1, ChronoUnit.HOURS);
Instant instant3 = instant.minus(1, ChronoUnit.HOURS);
Assertions.assertEquals(instant, instant.atZone(bstZone).toInstant());
Assertions.assertEquals(instant2, instant2.atZone(bstZone).toInstant());
Assertions.assertEquals(instant3, instant3.atZone(bstZone).toInstant());
}
{code}
Is there an example where the round trip does not provide an equal Instant?
> 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: Bug
> 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)
