# ELK truncates microseconds (nanoseconds) precision from RFC 3339 timestamps
**URL:** https://discuss.elastic.co/t/elk-truncates-microseconds-nanoseconds-precision-from-rfc-3339-timestamps/43619
**Category:** Elasticsearch
**Created:** [March 7, 2016, 5:10am UTC](https://discuss.elastic.co/t/elk-truncates-microseconds-nanoseconds-precision-from-rfc-3339-timestamps/43619 "2016-03-07T05:10:43Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Standa](https://discuss.elastic.co/u/Standa)
#### Post date: [March 7, 2016, 5:10am UTC](https://discuss.elastic.co/t/elk-truncates-microseconds-nanoseconds-precision-from-rfc-3339-timestamps/43619/1 "2016-03-07T05:10:43Z")
Hi,
I am fully aware that the issue i am going to write about was already discussed multiple times (e.g. see [https://github.com/elastic/elasticsearch/issues/10005](https://github.com/elastic/elasticsearch/issues/10005) , [https://github.com/elastic/logstash/issues/3530](https://github.com/elastic/logstash/issues/3530) etc).
Current version of Logstash (2.2.x) is able to correctly process log files with milliseconds precision.
When the log file contains higher precision timestamps (RFC 3339 format) all parts after milliseconds are truncated.
Because of this Kibana sorting is not working correctly. Messages from log files are displayed in wrong sequence.
This problem is even more apparent when multiline filter was applied (misplaced events that occured in the same milliseconds)
Many real world application needs higher precision.
Like databases (microseconds) or network infrastructure (nanoseconds).
If i understood correctly the problem lies inside the limits of the code handling timestamps.
In Logstash it is Joda-time classes package which limits precision to milliseconds.
Joda-time classes were used mainly because of not-so-great Java date and time classes. This situation is no longer true.
Hope you know, that in fact Joda-time classes authors are asking user to migrate to the new java.time classes (see [http://www.joda.org/joda-time/](http://www.joda.org/joda-time/)).
The authors of Joda-time greatly contributed to the all new java.time (JSR-310) classes which are core part of JDK onwards Java SE 8.
And JSR-310 java.time classes are based on nanoseconds.
I don't know about the requirements or roadmap of the Elastic/Logstash/Kibana package.
But i think simple solution of the problem (truncating timestamp after milliseconds part) could be replacing usage of Joda-Time classes with the java.time JSR-310 - which is, by design, working with nanoseconds.
Of course that would result in higher requirement of Java SE 8 for the Elastic/Logstash/Kibana package.
On the Elastic webpage i see that in requirements for Logstash (2.2.x) JRE 8 is highly recommended, but JRE 6/7 is still supported.
Java JRE 6 (Feb 2013) and JRE 7 (Apr 2015) had already reached End of life support period.
Thanks for any reply.
Best regards.
---
### Author:  [@KodrAus](https://discuss.elastic.co/u/KodrAus)
#### Post date: [April 15, 2016, 6:09am UTC](https://discuss.elastic.co/t/elk-truncates-microseconds-nanoseconds-precision-from-rfc-3339-timestamps/43619/2 "2016-04-15T06:09:59Z")
It looks like this is getting introduced, which will be great. As you say, milliseconds are just not sufficient for a whole bunch of use-cases.
I'm not a Java dev, so I'm not sure what kind of a breaking change in ES it would be, but if it doesn't land in 5.0 I'm not sure when would be an appropriate time to do it.
---
### Author:  [@jprante](https://discuss.elastic.co/u/jprante)
#### Post date: [April 15, 2016, 8:49am UTC](https://discuss.elastic.co/t/elk-truncates-microseconds-nanoseconds-precision-from-rfc-3339-timestamps/43619/3 "2016-04-15T08:49:33Z")
It's been created as an issue [https://github.com/elastic/elasticsearch/issues/12829](https://github.com/elastic/elasticsearch/issues/12829)
and I think it is a must-have for ES 5
Not sure if there is being worked on though.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 5, 2017, 10:59pm UTC](https://discuss.elastic.co/t/elk-truncates-microseconds-nanoseconds-precision-from-rfc-3339-timestamps/43619/4 "2017-07-05T22:59:01Z")