proper timestamp coercion to preserve microsecond precision

[colinsurprenant]

this refactors, extends and replaces #32 this will fix elastic/logstash#4565

[colinsurprenant]

@rikwasmus, @alex88, @guyboertje comments/reviews ?

[rikwasmus]

Thank you for your rewrite, I do agree that the logic deserves its own testable function.

However, 2 issues:

• @colinsurprenant: Could you alter your tests to feed it BigDecimals instead of floats? I have observed no issue with Time::at if the timestamp is actually a float, only being a BigDecimal (as it return from the parser as one) triggers the problem. It is now testing a condition which wasn't a problem in the first place, and not testing the condition which triggered it.
• @alex88 BigDecimal vs. float-wise: it's all about whether you'd like to handle big precision on arbitrary dates:
  • With the current unix-timestamp as it is, and the Gelf standard specifying milliseconds as max precision, floats seem fine / precise enough for current dates. However, on arbitrary large dates precision gets lost, but there may be a very limited use case of people actually using dates far in the future, assuming the receiving end even supports precision at that level instead of using floats internally. However, the whole point of this was precision was discarded, and it does not sit well for me to trade in some big precision loss for a conscious decision for still a loss, only less.
  • This code indeed introduces the creation of a new BigDecimal (which wasn't in my original quick & dirty pull request #32 ), however, in actual use the BigDecimal is already being created by the json parser, so if you're worried about the speed gain of floats vs. BigDecimals this should be handled in that parser, not here. To address your concerns, I would still advocate as in my original code to test for a BigDecimal and only add the extra precision if it's there (so, defaulting to float or even int if that's the input), but apparently, that part has been removed, so I assume there are some arguments against doing that?

And thank you both for your attention & help :)

[colinsurprenant]

@rikwasmus

Could you alter your tests to feed it BigDecimals instead of floats?

errr :stuck_out_tongue: thanks for respectfully reminding me to add the single test case this was all about in the first place! :laughing:

As you suggested and also @alex88 in the code comments, I optimized the coercion for the BigDecimal case and the rest. My original one-liner was an all-size-fits-all implementation but even if I think the performance impact is really minimal here, the code intent is a lot more clear now and, well, there is less casting and useless object creation done. :heavy_check_mark:

Let me know what you think.

[rikwasmus]

It looks awesome :smile: Except for a rogue timetstamp in the description of the JSON test (thanks for adding that as well) it gets my vote for shipping ;).

[colinsurprenant]

sweet djeezus, I keep on doing that typo :P ... elastic/logstash#4816

[guyboertje]

LGTM (I might have used build_event instead of new_event, because it does more than create a new event - but I not going to stand on ceremony)

[colinsurprenant]

Perfect! will merge and publish. Thanks all! :shipit:

[colinsurprenant]

Have a build error that will be fixed by elastic/logstash#4827 - want to merge that first then we will publish after, hopefully today.

[colinsurprenant]

elastic/logstash#4827 is merged but discovered another problem with BigDecimal handling. Fix awaiting reviews for merge in elastic/logstash#4838

[colinsurprenant]

published version 2.0.3