Use Java 8 Time instead of Joda in LS and any plugins.

[guyboertje]

• JRuby 9k now uses Java 8 Time classes but it still bundles Joda at an old version (2.8.2)
• The Java Event leverages the JRuby provided Joda libs.
• The Date Filter does too.
• The version of Joda in JRuby is quite old and does not have the latest tz info data and this cannot be updated using the TZUpdater tool fom Oracle.
  • Times from some timezones e.g. Venezuela will be converted to UTC incorrectly because the Venezuelans changed from -4:30 to -4:00 in 2016.
• Tests that compare a Timestamp with a Ruby Date can fail as the Ruby Time holds 6 digits of fractional seconds but Joda based Timestamp only holds 3 digits of fractional seconds.

[suyograo]

@guyboertje Is this going to break the interface for users w.r.t. the matcher patterns? I don't think Joda and Java 8 formatting of date patterns are compatible, no? I might be wrong though, haven't dug deep.

http://www.joda.org/joda-time/apidocs/org/joda/time/format/DateTimeFormat.html

[suyograo]

/cc @jordansissel who was researching this as well..

[ph]

@suyograo We might be able to create a translation layer between the 2, making it transparent to the user.

[ph]

From a discussion on zoom between @suyograo @jordansissel and myself we agreed to the following:

• We don't think this issue is a blocker for #7125
• We can do a follow-up PR to migrate to java time.

[colinsurprenant]

So would it be possible to keep Joda just for the pattern matching part and use Java 8 time everywhere else?? If it is, this would allow moving forward with proper Java 8 support and just keep Joda for the pattern matching until we decide what to do with that?

[ph]

@colinsurprenant Yup, I think possible to do that, we could use it the date filter and in the StringInterpolation classes.

[jordansissel]

possible to keep Joda just for the pattern matching part

This may not be necessary since java.time (JSR310) is based on Joda and hopefully has the same date format stuff.

[colinsurprenant]

are we moving forward with this?

[jordansissel]

@colinsurprenant yes, but we haven't done any compatibility research, testing, or code yet.

If you'd like to work on this, I am in favor of it being delivered. I think it's two things:

1) Update Logstash::Timestamp to be based on java.time.Instant (or whatever is appropriate) 2) Update Date filter to use java.time's parser library

[colinsurprenant]

my own backlog is long but If we believe this is important then we can look into prioritizing it somehow. I asked if we were moving forward more to know if this was still valid or not and it is per your comment @jordansissel.

[jordansissel]

Indeed. Long is the backlog ;)

I am +1 on moving forward with this whenever/wherever we can fit it into our roadmap and whatnot.

[ahrex]

Hello!

I got here by way of #7463, #7474, and https://github.com/elastic/logstash/issues/5606#issuecomment-302221341, and was wondering if there's any progress / prioritization for switching underlying time libraries!

We're using Logstash for an application that would greatly benefit from nanosecond granularity, and it would be nice to know what the plan is for switching over.

Thanks!

[roaksoax]

Hi @ahrex ,

Benefiting from Nanosecond granularity is currently on our roadmap, but unfortunately, it is not something we will be able to tackle in the short term. That said, we are constantly evaluating the roadmap and hoping to have better news in 3-6 months as to when we would be able to improve here!

[benbuzbee]

That said, we are constantly evaluating the roadmap and hoping to have better news in 3-6 months as

Just checking in 😁