# Date Match is setting incorrect timestamp / not actually setting timestamp **URL:** \ **Category:** Logstash\ **Created:** [January 27, 2021, 11:43am UTC](https://discuss.elastic.co/t/date-match-is-setting-incorrect-timestamp-not-actually-setting-timestamp/262363 "2021-01-27T11:43:51Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![beirtipol](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/beirtipol/32/82977_2.png) [@beirtipol](https://discuss.elastic.co/u/beirtipol)\ **Post date:** [January 27, 2021, 11:43am UTC](https://discuss.elastic.co/t/date-match-is-setting-incorrect-timestamp-not-actually-setting-timestamp/262363/1 "2021-01-27T11:43:51Z")
I have the following filter in my logstash pipeline: ```auto date { match => ["[fields][serverrequest][starttime]", "UNIX_MS" ] tag_on_failure => ["serverrequest_logstyle_dateparsefailure"] } ``` However, the resulting document in ElasticSearch is showing a timestamp value which does not match the parsed field e.g. document: ```auto @timestamp: Jan 27, 2021 @ 11:11:14.891 fields.serverrequest.starttime: 1611722342306 ``` Parsing that starttime on [epochconverter.com](http://epochconverter.com) gives me Wednesday, 27 January 2021 04:39:02.306 which is what I expect from the other document details, and also simply looking at the last 3 digits in the starttime field. I can't see any backlog on the filebeat / logstash monitoring that would explain a ~7 hour delay, and I don't see any documents with a timestamp in the future. I'm at a loss to explain what's going on. ---
**Author:** ![beirtipol](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/beirtipol/32/82977_2.png) [@beirtipol](https://discuss.elastic.co/u/beirtipol)\ **Post date:** [January 27, 2021, 2:23pm UTC](https://discuss.elastic.co/t/date-match-is-setting-incorrect-timestamp-not-actually-setting-timestamp/262363/2 "2021-01-27T14:23:33Z")
Gah, foolishly I was using the wrong syntax to access a nested field. I should have used "fields.serverrequest.starttime" ---
**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\ **Post date:** [January 27, 2021, 4:34pm UTC](https://discuss.elastic.co/t/date-match-is-setting-incorrect-timestamp-not-actually-setting-timestamp/262363/3 "2021-01-27T16:34:14Z")
No, you used the right syntax to access a nested field, I guess what you have is a field with periods in its name, which is very different. ---
**Author:** ![beirtipol](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/beirtipol/32/82977_2.png) [@beirtipol](https://discuss.elastic.co/u/beirtipol)\ **Post date:** [January 27, 2021, 5:02pm UTC](https://discuss.elastic.co/t/date-match-is-setting-incorrect-timestamp-not-actually-setting-timestamp/262363/4 "2021-01-27T17:02:53Z")
Huh.. Have I done something silly in my Grok which is using field names with periods instead of nested fields then? Here's the full section ```auto grok { match => { "message" => "^%{NUMBER:fields.serverrequest.starttime}\|%{NUMBER:fields.serverrequest.responsetime:int}\|%{NUMBER:fields.serverrequest.sqltime:int}\|%{NUMBER:fields.serverrequest.querycount:int}\|%{NUMBER:fields.sql.numberofrowsread:int}\|%{NUMBER:fields.sql.resultsetopentime:int}\|%{NUMBER:fields.serverrequest.beginfreememory}\|%{NUMBER:fields.serverrequest.endfreememory}\|%{NUMBER:fields.serverrequest.totalmemory}\|%{NUMBER:fields.serverrequest.wftime:int}\|%{NUMBER:fields.serverrequest.events:int}\|%{NUMBER:fields.serverrequest.usedjdbcconnections:int}\|%{NUMBER:fields.serverrequest.available:int}\|(%{IP:fields.client.ip})?\|(%{DATA:fields.client.username}/%{DATA:fields.client.process})?\|%{NUMBER:fields.requestid:int}\|(?.*?)\|%{GREEDYDATA:fields.methodcall}$"} tag_on_failure => ["serverrequest_logstyle_grokparsefailure"] } mutate { remove_field => ["message"] convert => { "fields.serverrequest.executetime" => "integer" } } date { match => ["fields.serverrequest.starttime", "UNIX_MS"] tag_on_failure => ["serverrequest_logstyle_dateparsefailure"] } ``` ---
**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\ **Post date:** [January 27, 2021, 5:15pm UTC](https://discuss.elastic.co/t/date-match-is-setting-incorrect-timestamp-not-actually-setting-timestamp/262363/5 "2021-01-27T17:15:09Z")
> [@beirtipol](#): > > `"^%{NUMBER:fields.serverrequest.starttime}\|%` That creates a field called `fields.serverrequest.starttime` with two periods in the name. If you want a starttime field inside the serverrequest object inside the fields object you would have to use `%{NUMBER:[fields][serverrequest][starttime]}`. kibana and elasticsearch use the same name for both things, logstash does not. There was a time (around 5.x if I recall correctly) when elasticsearch disallowed periods in field names, but then later on they were allowed again. ---
**Author:** ![beirtipol](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/beirtipol/32/82977_2.png) [@beirtipol](https://discuss.elastic.co/u/beirtipol)\ **Post date:** [January 27, 2021, 5:57pm UTC](https://discuss.elastic.co/t/date-match-is-setting-incorrect-timestamp-not-actually-setting-timestamp/262363/6 "2021-01-27T17:57:24Z")
Understood, thanks very much for clarifying. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [February 24, 2021, 5:57pm UTC](https://discuss.elastic.co/t/date-match-is-setting-incorrect-timestamp-not-actually-setting-timestamp/262363/7 "2021-02-24T17:57:31Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.