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
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
>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
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
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
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
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 params =
