# Using @timestamp field in SQL queries

**URL:** <https://discuss.elastic.co/t/using-timestamp-field-in-sql-queries/147701>\
**Category:** Elasticsearch\
**Created:** [September 7, 2018, 11:13am UTC](https://discuss.elastic.co/t/using-timestamp-field-in-sql-queries/147701 "2018-09-07T11:13:05Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![prwillmot](https://avatars.discourse-cdn.com/v4/letter/p/ba8739/32.png) [@prwillmot](https://discuss.elastic.co/u/prwillmot)\
**Post date:** [September 7, 2018, 11:13am UTC](https://discuss.elastic.co/t/using-timestamp-field-in-sql-queries/147701/1 "2018-09-07T11:13:05Z")

</div>

given a simple sample index, the following works perfectly running from Kibana dev console and includes @timestamp as a column in the output:

POST \_xpack/sql?format=txt  
{  
"query":"SELECT \* FROM sampleindex LIMIT 10"  
}

and, the following also works as expected assuming fieldA and fieldB exist in the index:

POST \_xpack/sql?format=txt  
{  
"query":"SELECT fieldA, fieldB FROM sampleindex LIMIT 10"  
}

BUT, when I try to include the @timestamp column in the select list I get error (see end of this post):

POST \_xpack/sql?format=txt  
{  
"query":"SELECT @timestamp, fieldA, fieldB FROM sampleindex LIMIT 10"  
}

Do we need to use some form of escape prefix for the '@'?

ERROR OUTPUT starts here:

{  
"error": {  
"root\_cause": [  
{  
"type": "parsing\_exception",  
"reason": "line 1:8: mismatched input '@timestamp' expecting {'(', 'ANALYZE', 'ANALYZED', 'CAST', 'CATALOGS', 'COLUMNS', 'DEBUG', 'EXECUTABLE', 'EXISTS', 'EXPLAIN', 'EXTRACT', 'FALSE', 'FORMAT', 'FUNCTIONS', 'GRAPHVIZ', 'LEFT', 'MAPPED', 'MATCH', 'NOT', 'NULL', 'OPTIMIZED', 'PARSED', 'PHYSICAL', 'PLAN', 'RIGHT', 'RLIKE', 'QUERY', 'SCHEMAS', 'SHOW', 'SYS', 'TABLES', 'TEXT', 'TRUE', 'TYPE', 'TYPES', 'VERIFY', '{FN', '{D', '{T', '{TS', '{GUID', '+', '-', '_', '?', STRING, INTEGER\_VALUE, DECIMAL\_VALUE, IDENTIFIER, DIGIT\_IDENTIFIER, QUOTED\_IDENTIFIER, BACKQUOTED\_IDENTIFIER}"  
}  
],  
"type": "parsing\_exception",  
"reason": "line 1:8: mismatched input '@timestamp' expecting {'(', 'ANALYZE', 'ANALYZED', 'CAST', 'CATALOGS', 'COLUMNS', 'DEBUG', 'EXECUTABLE', 'EXISTS', 'EXPLAIN', 'EXTRACT', 'FALSE', 'FORMAT', 'FUNCTIONS', 'GRAPHVIZ', 'LEFT', 'MAPPED', 'MATCH', 'NOT', 'NULL', 'OPTIMIZED', 'PARSED', 'PHYSICAL', 'PLAN', 'RIGHT', 'RLIKE', 'QUERY', 'SCHEMAS', 'SHOW', 'SYS', 'TABLES', 'TEXT', 'TRUE', 'TYPE', 'TYPES', 'VERIFY', '{FN', '{D', '{T', '{TS', '{GUID', '+', '-', '_', '?', STRING, INTEGER\_VALUE, DECIMAL\_VALUE, IDENTIFIER, DIGIT\_IDENTIFIER, QUOTED\_IDENTIFIER, BACKQUOTED\_IDENTIFIER}",  
"caused\_by": {  
"type": "input\_mismatch\_exception",  
"reason": null  
}  
},  
"status": 400  
}

---

<div class="post-metadata">

**Author:** ![Andrei\_Stefan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrei_stefan/32/47533_2.png) [@Andrei\_Stefan](https://discuss.elastic.co/u/Andrei_Stefan)\
**Post date:** [September 10, 2018, 6:39am UTC](https://discuss.elastic.co/t/using-timestamp-field-in-sql-queries/147701/2 "2018-09-10T06:39:29Z")

</div>

@prwillmot you need to escape that field name with double quotes. Something like `"query": "SELECT \"@timestamp\", fieldA, fieldB FROM sampleindex LIMIT 10"`.

---

<div class="post-metadata">

**Author:** ![prwillmot](https://avatars.discourse-cdn.com/v4/letter/p/ba8739/32.png) [@prwillmot](https://discuss.elastic.co/u/prwillmot)\
**Post date:** [September 10, 2018, 7:04am UTC](https://discuss.elastic.co/t/using-timestamp-field-in-sql-queries/147701/3 "2018-09-10T07:04:36Z")

</div>

many thanks, this works perfectly

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [October 8, 2018, 7:04am UTC](https://discuss.elastic.co/t/using-timestamp-field-in-sql-queries/147701/4 "2018-10-08T07:04:40Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.