-
Notifications
You must be signed in to change notification settings - Fork 993
Adding support for the date_nanos field type #1803
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the code suffer from any loss of precision issues from using nano time on older time libraries? Can we add a test to make sure the serialization for date nanos works?
You're right -- the parser only produces milliseconds, and we're only grabbing milliseconds from it at https://github.com/masseyke/elasticsearch-hadoop/blob/feature/date-nanos/spark/core/src/main/scala/org/elasticsearch/spark/serialization/ScalaValueReader.scala#L181. |
OK, I've changed it so that for date_nanos fields we keep track of the nanoseconds the whole way through. In addition to the unit tests, I manually pulled data out of an index in spark shell and wrote it out to a new index, and the nanoseconds were still correctly there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Adding support for the date_nanos field type. This field type is now treated in the same way as the date field type, except that we keep track of nanoseconds. Closes elastic#1653
Adding support for the date_nanos field type. This field type is now treated in the same way as the date field type, except that we keep track of nanoseconds. Closes elastic#1653
In #1803 we added support for the data_nanos Elasticsearch field type. However there is a bug in that sets the zone offset to the offset right now, as opposed to what the zone offset was at the time of the date. So for example if the date was 2015-01-01T06:10:30.123456789-06:00, then if you read that date after daylight saving had begun you would see it as 2015-01-01T06:10:30.123456789-05:00.
In elastic#1803 we added support for the data_nanos Elasticsearch field type. However there is a bug in that sets the zone offset to the offset right now, as opposed to what the zone offset was at the time of the date. So for example if the date was 2015-01-01T06:10:30.123456789-06:00, then if you read that date after daylight saving had begun you would see it as 2015-01-01T06:10:30.123456789-05:00.
In elastic#1803 we added support for the data_nanos Elasticsearch field type. However there is a bug in that sets the zone offset to the offset right now, as opposed to what the zone offset was at the time of the date. So for example if the date was 2015-01-01T06:10:30.123456789-06:00, then if you read that date after daylight saving had begun you would see it as 2015-01-01T06:10:30.123456789-05:00.
In #1803 we added support for the data_nanos Elasticsearch field type. However there is a bug in that sets the zone offset to the offset right now, as opposed to what the zone offset was at the time of the date. So for example if the date was 2015-01-01T06:10:30.123456789-06:00, then if you read that date after daylight saving had begun you would see it as 2015-01-01T06:10:30.123456789-05:00.
In #1803 we added support for the data_nanos Elasticsearch field type. However there is a bug in that sets the zone offset to the offset right now, as opposed to what the zone offset was at the time of the date. So for example if the date was 2015-01-01T06:10:30.123456789-06:00, then if you read that date after daylight saving had begun you would see it as 2015-01-01T06:10:30.123456789-05:00.
Adding support for the date_nanos field type. This field type is now treated in the same way as the date field type.
Closes #1653