You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Felix Schumacher <fe...@internetallee.de> on 2020/03/07 13:56:32 UTC
failing timeshift test
Hi all,
the test TestTimeShiftFunction#testNowWithComplexPeriod is failing
probably due to a transition period shortly before day light saving time
switch.
The code is
@Test
public void testNowWithComplexPeriod() throws Exception {
Collection<CompoundVariable> params =
makeParams("yyyy-MM-dd'T'HH:mm:ss", "", "P10DT-1H-5M5S", "");
function.setParameters(params);
value = function.execute(result, null);
LocalDateTime futureDate =
LocalDateTime.now().plusDays(10).plusHours(-1).plusMinutes(-5).plusSeconds(5);
LocalDateTime futureDateFromFunction = LocalDateTime.parse(value);
assertThat(futureDateFromFunction, within(1, ChronoUnit.SECONDS,
futureDate));
}
any idea how to make it aware of this transition period without giving
up a non timezone aware current time?
I thought of checking the day light settings for the locale for the
current and the future date, and calculating a difference if necessary.
Felix
Re: failing timeshift test
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 08.03.20 um 13:56 schrieb Felix Schumacher:
> Am 08.03.20 um 13:53 schrieb Vladimir Sitnikov:
>>> interpretation of LocalTime addition operations and parsing
>> Well, the function itself does a lot of time parsing, so I am nowhere sure
>> if it contains bug or not.
>> Did you mean the test fails at the specific date only?
> Yes, my thinking was that it started to fail 10 days before dst switch
> (in new york), but I am not sure anymore, that that was really the cause.
So, now I have set up a test vm with date set to 2020-03-04 and a
TZ=America/New_York.
Running the build step will fail reliable with
FAILURE 0.3sec, org.apache.jmeter.functions.TestTimeShiftFunction >
testNowWithComplexPeriod()
java.lang.AssertionError:
Expected: the date is within 1 seconds of Fri, 13 Mar 2020
06:27:44.409 PM
but: the date is Fri, 13 Mar 2020 07:27:44.000 PM and 3599
seconds different
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:964)
at org.junit.Assert.assertThat(Assert.java:930)
at
org.apache.jmeter.functions.TestTimeShiftFunction.testNowWithComplexPeriod(TestTimeShiftFunction.java:116)
FAILURE 0.4sec, 12 completed, 1 failed, 0 skipped,
org.apache.jmeter.functions.TestTimeShiftFunction
If I add the DST offset between those dates (Mar-04 and Mar-13) by using
something like
+ private int dstOffset(Date from, Date to) {
+ Calendar cal = Calendar.getInstance(); // use the locale and
timezone of the current machine
+ cal.setTime(from);
+ int fromOffset = cal.get(Calendar.DST_OFFSET);
+ cal.setTime(to);
+ int toOffset = cal.get(Calendar.DST_OFFSET);
+ if (fromOffset == toOffset) {
+ return 0;
+ }
+ return (fromOffset - toOffset) / 1000;
+ }
the failure is fixed. So I believe that my first idea was correct.
Felix
>> However, the concurrent execution of tests that alter timezone is not
>> something we intended to do.
>> Technically speaking, JUnit5 has ResourceLock notation (see
>> https://github.com/junit-team/junit5/issues/2142#issuecomment-596199239 )
> Right, that is something we didn't intend to do.
>
> Felix
>
>> Vladimir
>>
Re: failing timeshift test
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 08.03.20 um 13:53 schrieb Vladimir Sitnikov:
>> interpretation of LocalTime addition operations and parsing
> Well, the function itself does a lot of time parsing, so I am nowhere sure
> if it contains bug or not.
> Did you mean the test fails at the specific date only?
Yes, my thinking was that it started to fail 10 days before dst switch
(in new york), but I am not sure anymore, that that was really the cause.
>
> However, the concurrent execution of tests that alter timezone is not
> something we intended to do.
> Technically speaking, JUnit5 has ResourceLock notation (see
> https://github.com/junit-team/junit5/issues/2142#issuecomment-596199239 )
Right, that is something we didn't intend to do.
Felix
>
> Vladimir
>
Re: failing timeshift test
Posted by Vladimir Sitnikov <si...@gmail.com>.
>interpretation of LocalTime addition operations and parsing
Well, the function itself does a lot of time parsing, so I am nowhere sure
if it contains bug or not.
Did you mean the test fails at the specific date only?
However, the concurrent execution of tests that alter timezone is not
something we intended to do.
Technically speaking, JUnit5 has ResourceLock notation (see
https://github.com/junit-team/junit5/issues/2142#issuecomment-596199239 )
Vladimir
Re: failing timeshift test
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 08.03.20 um 12:55 schrieb Vladimir Sitnikov:
> I guess the issue there is the test relies on TimeZone.getDefault(),
> however,
> there's org.apache.jmeter.functions.TestDateTimeConvertFunction#testDateTimeConvertEpochTime
> which alters the default time zone.
>
> Let's see if something like https://github.com/apache/jmeter/pull/560 can
> workaround this.
Ah, you think it is a side effect. I thought it would be a different
interpretation of LocalTime addition operations and parsing.
My thought was, that either parsing or addition would use the current
timezone and the other one the timezone of the future date.
Especially as it happened on the JDK 13 instance, which has another TZ
set (New York, where dst starts today).
Felix
>
> Vladimir
>
Re: failing timeshift test
Posted by Vladimir Sitnikov <si...@gmail.com>.
I guess the issue there is the test relies on TimeZone.getDefault(),
however,
there's org.apache.jmeter.functions.TestDateTimeConvertFunction#testDateTimeConvertEpochTime
which alters the default time zone.
Let's see if something like https://github.com/apache/jmeter/pull/560 can
workaround this.
Vladimir
Re: failing timeshift test
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 07.03.20 um 14:56 schrieb Felix Schumacher:
> Hi all,
>
> the test TestTimeShiftFunction#testNowWithComplexPeriod is failing
> probably due to a transition period shortly before day light saving time
> switch.
Seems the test failed on travis and for jdk 13, only
(https://travis-ci.org/apache/jmeter/jobs/656886259)
Felix
>
> The code is
>
> @Test
> public void testNowWithComplexPeriod() throws Exception {
> Collection<CompoundVariable> params =
> makeParams("yyyy-MM-dd'T'HH:mm:ss", "", "P10DT-1H-5M5S", "");
> function.setParameters(params);
> value = function.execute(result, null);
> LocalDateTime futureDate =
> LocalDateTime.now().plusDays(10).plusHours(-1).plusMinutes(-5).plusSeconds(5);
> LocalDateTime futureDateFromFunction = LocalDateTime.parse(value);
> assertThat(futureDateFromFunction, within(1, ChronoUnit.SECONDS,
> futureDate));
> }
>
> any idea how to make it aware of this transition period without giving
> up a non timezone aware current time?
>
> I thought of checking the day light settings for the locale for the
> current and the future date, and calculating a difference if necessary.
>
> Felix
>