Prior to 6.8 where only joda time was used in Elasticsearch the only way to update timezone DB was to update joda time library.
Timezone DB is released by https://www.iana.org/time-zones this happens more frequently than JDK or joda releases. Changes occurs when for instanc a country decides to tweak their DST.
Since 6.8 we also use java.time and java allows updating timezone DB with timezone updater tool There is a file in $JAVA_HOME/lib/tzdb.dat (for jdk12) with timezone information. I am not aware this is configurable.
We can rely on a user to update his JDK with latest timezone data if he uses his own JDK. We can also keep on updating joda for 7.x and 6.8 releases.
I think we should be keeping both joda and java.time timezone dbs on the same version. If a user is using a newer timezone DB in 6.8 or 7.x and decides to upgrade to use java.time he would notice the breaking change (non existing or differently configured timezones)
However the problem remains for our bundled JDKs. I suspect we should consider updating these JDKs before we release. - as well as when we update our joda.time containing new timezone db. We did that recently which highlighted the problem #49748
We should be also updating the JDKs we use for testing (whenever a joda dependency is upgraded)
Prior to 6.8 where only joda time was used in Elasticsearch the only way to update timezone DB was to update joda time library.
Timezone DB is released by https://www.iana.org/time-zones this happens more frequently than JDK or joda releases. Changes occurs when for instanc a country decides to tweak their DST.
Since 6.8 we also use java.time and java allows updating timezone DB with timezone updater tool There is a file in
$JAVA_HOME/lib/tzdb.dat(for jdk12) with timezone information. I am not aware this is configurable.We can rely on a user to update his JDK with latest timezone data if he uses his own JDK. We can also keep on updating joda for 7.x and 6.8 releases.
I think we should be keeping both joda and java.time timezone dbs on the same version. If a user is using a newer timezone DB in 6.8 or 7.x and decides to upgrade to use java.time he would notice the breaking change (non existing or differently configured timezones)
However the problem remains for our bundled JDKs. I suspect we should consider updating these JDKs before we release. - as well as when we update our joda.time containing new timezone db. We did that recently which highlighted the problem #49748
We should be also updating the JDKs we use for testing (whenever a joda dependency is upgraded)