Remove joda date deprecation message on startup in 6.8

[spinscale]

When starting up Elasticsearch 6.8, there is always a deprecation
message logged like this

[WARN ][o.e.d.c.j.Joda ] [A2Wr_Jx] 'y' year should be replaced with 'u'. Use 'y' for year-of-era. Prefix your date format with '8' to use the new specifier.

tracing this down, result in the LicenseService being the culprit using
an deprecated date. This switches to a java time based date.

Note: master/7.x/7.3 branches use yyyy in java time and not joda time, but as this is year-of-era, that might be fine for licensing.

Closes #45483

[elasticmachine]

Pinging @elastic/es-core-infra

[pgomulka]

LGTM, but maybe we should use yyyy in 6.8? It don't think we necessarily need u here.

[spinscale]

you mean for consistency among the 7.x implementation? that makes sense.

[rjernst]

y is specifically for year of era, meaning the format should contain era. I think we should stick with u.

[pgomulka]

But isn't era defaulted from chronology? Don't have a doc handy but I think i have seen this mentioned

[pgomulka]

I see your point in terms of resolve style. Era will be defaulted only in lenient or smart style. Not sure if this is a problem when parsing /formatting though. Even in strict mode.

https://docs.oracle.com/javase/8/docs/api/java/time/chrono/AbstractChronology.html#resolveDate-java.util.Map-java.time.format.ResolverStyle-

[richiejarvis]

@spinscale @pgomulka What is the feeling regarding whether the format change is/is not actually needed for the common y to u situation?

Folks are seeing it in their deprecation logs, and are wondering whether they really need to change it. My understanding (and please correct me if I am wrong) is that using YEAR_OF_ERA will not actually make any difference unless in certain exacting situations. Japanese Calendar or pre-1AD dates were the 2 I found. Especially as using the parse features of the Formatter should mean no difference in behaviour iirc.

Thanks in advance,

Richie

[pgomulka]

Hey @richiejarvis , most of the time it is safe as we made this a bit more flexible and allow using year_of_era in similar way as year in elasticsearch. We have enabled Strict date resolving, but still allow year_of_era to be passed without an era. see #46675

I would however advice to update this if possible.

I will be working on an issue that would make this upgrade more smooth #45548 This is high on my list and will look into this soon.

Also see if support support help page might be useful https://github.com/elastic/support-knowledge-articles/blob/master/Knowledge%20Share/Elasticsearch%20Joda%20-%20Java%20migration.md