[CI] CronEvalToolTests testEnsureDateIsShownInRootLocale sometimes fails

[droberts195]

CronEvalToolTests testEnsureDateIsShownInRootLocale sometimes fails. An example is https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+matrix-java-periodic/ES_BUILD_JAVA=java11,ES_RUNTIME_JAVA=java11,nodes=virtual&&linux/67/consoleText

The exception is:

   > Throwable #1: java.lang.AssertionError: 
   > Expected: a string containing "] in UTC, local time is"
   >      but: was "Valid!
   > Now is [Mon, 19 Nov 2018 05:20:04] in UTC
   > Here are the next 1 times this cron expression will trigger:
   > 1.	Mon, 2 Jan 2040 11:00:00
   > "

The , local time is bit is missing.

This did not reproduce locally for me:

./gradlew :x-pack:plugin:watcher:test \
  -Dtests.seed=204FA128FA77A81C \
  -Dtests.class=org.elasticsearch.xpack.watcher.trigger.schedule.tool.CronEvalToolTests \
  -Dtests.method="testEnsureDateIsShownInRootLocale" \
  -Dtests.security.manager=true \
  -Dtests.locale=ar-SS \
  -Dtests.timezone=Asia/Seoul \
  -Dcompiler.java=11 \
  -Druntime.java=11

[elasticmachine]

Pinging @elastic/es-core-infra

[droberts195]

Test is muted in master in 2ee25c8

[droberts195]

Some other builds where the same test failed are:

• https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+multijob-unix-compatibility/os=debian/67/console
• https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+release-tests/115/console
• https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+multijob-unix-compatibility/os=oraclelinux/67/console

[astefan]

I was able to reproduce this via Eclipse only (it seems gradle won't let me pass the same in the command line) by passing -Duser.timezone=UTC to the VM starting the test. The way the test does the UTC timezone comparison is a bit different than what the Watcher code does it:

• the test goes straight to java.util.TimeZone.getDefault()
• Watcher code uses org.joda.time.DateTimeZone.forTimeZone(null) which first looks at user.timezone system property and, if that one doesn't exist, it takes the timezone from TimeZone.getDefault().

Not sure how would this scenario reach this stage so that the comparison fails... somehow user.timezone must have been set on the box the test ran in which made the test to fail...

@spinscale @rjernst my investigation above does sound right to you? Is it worth changing the test to use the same approach for local timezone - UTC comparison as CronEvalTool?

[astefan]

Reproduceable with gradle command: gradlew :x-pack:plugin:watcher:test -Dtests.seed=204FA128FA77A81C -Dtests.class=org.elasticsearch.xpack.watcher.trigger.schedule.tool.CronEvalToolTests -Dtests.method="testEnsureDateIsShownInRootLocale" -Dtests.security.manager=true -Dtests.locale=ar-SS -Dtests.timezone=UTC -Dcompiler.java=11 -Druntime.java=11 -Dtests.jvm.argline="-Duser.timezone=UTC"

[pgomulka]

@astefan @spinscale when using java-time ZoneId.systemDefault in both test and CronEvalTool the behaviour will be as suggested by Andrei

to use the same approach for local timezone - UTC comparison as CronEvalTool?
I will enable this test once my main PR #35809 is merged