# Date Field not properly recognised by Kibana 4
**URL:** https://discuss.elastic.co/t/date-field-not-properly-recognised-by-kibana-4/72082
**Category:** Kibana
**Created:** [January 18, 2017, 8:23pm UTC](https://discuss.elastic.co/t/date-field-not-properly-recognised-by-kibana-4/72082 "2017-01-18T20:23:45Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@sharon.c](https://discuss.elastic.co/u/sharon.c)
#### Post date: [January 18, 2017, 8:23pm UTC](https://discuss.elastic.co/t/date-field-not-properly-recognised-by-kibana-4/72082/1 "2017-01-18T20:23:45Z")
I have two date fields in index, record\_time and @timestamp, the values of these two fields should be the same, and their format is different. record\_time is generated by php code, and @timestamp is generated by logstash automatically.
This is the screen catch of Kibana indice setting, you can see they are both recognised as date field
This is the screen catch of the two field presentation in Kibana discover page
This is the screen catch of the raw data format of the two field presentation in Kibana discover page
The following is screen catch when I use **record\_time** field range aggregation on Kibana to aggregate count for each hour
The following is screen catch when I use **@timestamp** field range aggregation on Kibana to aggregate count for each hour
You can see when I use **@timestamp** , I can get aggregated result, but when I use **record\_time** the aggregated result is not 0 ( kibana does not recognise record\_time field properly)
Not only in date range visualisation, but also other visualisation like date histogram, if I use record\_time the result is empty.
How can I make Kibana use this field correctly?
---
### Author:  [@LeeDr](https://discuss.elastic.co/u/LeeDr)
#### Post date: [January 18, 2017, 8:29pm UTC](https://discuss.elastic.co/t/date-field-not-properly-recognised-by-kibana-4/72082/2 "2017-01-18T20:29:35Z")
Hi Sharon,
See if this resolves your issue; [Date Histogram Problem](https://discuss.elastic.co/t/date-histogram-problem/71969)
Regards,
Lee
---
### Author:  [@sharon.c](https://discuss.elastic.co/u/sharon.c)
#### Post date: [January 18, 2017, 8:45pm UTC](https://discuss.elastic.co/t/date-field-not-properly-recognised-by-kibana-4/72082/3 "2017-01-18T20:45:02Z")
Hi LeeDr, Thank you for your prompt reply.
I actually tried, it still does not work.
when I use @timestamp it works fine, I can see the data from discovery page,
but when I choose record\_time when I add new index in kibana
It does not show any documents in the discover page.
Actually Elasticsearch does not respond properly if I use record\_time to do time range query in Sense interface, but if I use @timetamp to define the range, the result is correct:
---
### Author:  [@LeeDr](https://discuss.elastic.co/u/LeeDr)
#### Post date: [January 18, 2017, 10:07pm UTC](https://discuss.elastic.co/t/date-field-not-properly-recognised-by-kibana-4/72082/4 "2017-01-18T22:07:24Z")
Hi Sharon,
What version of Kibana are you on? I might start up that version and try to replicate your case since I'm running a 5.x version.
I'm not sure yet what the problem is but I can show you what an index of mine with 2 date type fields looks like as a comparison.
In this index I have a `@timestamp` and `system.process.cpu.start_time`
The date formats of both of mine are the same with the `T` between the date and time parts.
And in the JSON view, after the \_source block, there is a "fields" block which shows those 2 timestamps with their milliseconds-since-the-epoch number format. Do you have that "fields" section? It might not be the same since I'm on 5.x and you're on Kibana 4.x.
And I confirmed I can create another index pattern using my `system.process.cpu.start_time` as the time-field name, and my Discover tab works fine.
And I also opened this to see the mapping; [http://localhost:9200/metricbeat-2017.01.18/\_mapping](http://localhost:9200/metricbeat-2017.01.18/_mapping) and I see those 2 date fields again.
---
### Author:  [@sharon.c](https://discuss.elastic.co/u/sharon.c)
#### Post date: [January 18, 2017, 11:11pm UTC](https://discuss.elastic.co/t/date-field-not-properly-recognised-by-kibana-4/72082/5 "2017-01-18T23:11:02Z")
I am using Kibana 4.5 with Elasticsearch 2.3
Maybe my date field is not in correct format, that's why Elasticsearch does not use it properly.
The date format I am using is in this format yyyy-mm-dd HH:mm:ss, when I use logstash to import the values and I defined this date field in elasticsearch template, there is no error from logstash during the importing process.
---
### Author:  [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)
#### Post date: [January 19, 2017, 7:51am UTC](https://discuss.elastic.co/t/date-field-not-properly-recognised-by-kibana-4/72082/6 "2017-01-19T07:51:41Z")
@sharon.c The one difference between those two fields is that the `@timestamp` includes time zone, so is converted to UTC before being indexed, while `record_time` doesn't and so is treated as UTC already.
In the screen capture of the raw data format, you can see that the two values aren't the same. `@timestamp` has time 19:49 while `record_time` has time `14:49`. In the screen cap of the field presentation just above that, the two dates are both rendered as 14:49, I think because Kibana sees that `@timestamp` has a time zone and so converts it to your local time zone.
I'm guessing at the reason here as I don't know how much data you have or what periods it covers. The raw JSON query that you show is a bit weird, as it is looking for data between Aug 1 2016 to Sep 7 2016.
Try doing the following:
```auto
GET elkstats_record_leads*/_validate_query?explain
{
"query": {
"range": {
"@timestamp": {
"gte": ".....some value...",
"lte": ".....some value..."
}
}
}
}
```
And then substitute `record_time` for `@timestamp` and compare the outputs
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [February 16, 2017, 7:52am UTC](https://discuss.elastic.co/t/date-field-not-properly-recognised-by-kibana-4/72082/7 "2017-02-16T07:52:23Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.