今天在消費kafka數據到elasticsearch（以下簡稱es）中的時候遇到一個問題，也是一個坑，折騰了半天，后來發現得來全不費工夫，全是白忙活啊！！！
問題如下：
kafka數據中有一個字段是時間字符串，格式為：‘2018-05-31 16：33:45：234’
為了方便以后根據日期檢索數據，es里已將該字段設置為date類型，
接下來便開始了str到date轉換的艱辛之路......
嘗試過的解決辦法如下：
1、使用datetime將str轉換為datetime對象
輸出結果如下：
好像成功了，於是開始導入es，但是出錯了
這種轉換對數據的格式要求比較苛刻，一旦原始字符串格式稍有變化，則拋出異常
所以下一步，捕獲異常，將kafka中日期格式不符合要求的數據寫到日志文件中，個別處理
最后：
elasticsearch原生支持date類型,json格式通過字符來表示date類型。所以在用json提交日期至elasticsearch的時候，es會隱式轉換，把es認為是date類型的字符串直接轉為date類型。至於什么樣的字符串es會認為可以轉換成date類型，參考elasticsearch官網介紹https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-date-format.html。
date類型是包含時區信息的，如果我們沒有在json代表日期的字符串中顯式指定時區，對es來說沒什么問題，但是如果通過kibana顯示es里的數據時，就會出現問題，數據的時間會晚8個小時。因為kibana從es里讀取的date類型數據，沒有時區信息，kibana會默認當作0時區來解析，但是kibana在通過瀏覽器展示的時候，會通過js獲取當前客戶端機器所在的時區，也就是東八區，所以kibana會把從es得到的日期數據減去8小時。這里就會導致kibana經常遇到的“數據時間延遲8小時”的問題。
所以最佳實踐方案就是：我們在往es提交日期數據的時候，直接提交帶有時區信息的日期字符串，如：“2016-07-15T12:58:17.136+0800
————————————————
版權聲明：本文為CSDN博主「威震四海」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/Beyond_F4/article/details/80528230