-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
CSV export date not applying correct date format (from a saved search in a dashboard) #56153
Comments
I can also confirm this behavior. The export works well when done in the context of "Discover" but fails to apply the new format when done in the context of a "Dashboard". It's unexpected behavior. Hopefully, this is an easy fix. Thanks for posting @daohodac. |
Pinging @elastic/kibana-reporting-services (Team:Reporting Services) |
Thanks for filing this. It looks like a valid bug. |
This can be fixed for the "date" type of fields, but it looks like fixing "date_nanos" will require similar work as #30264 |
Fixed in #67027
|
Closed in #67027 |
Kibana version:
7.5.1
Elasticsearch version:
7.5.1
Server OS version:
debian 9
Browser version:
chrome
Browser OS version:
78.0.3904.108
Original install method (e.g. download page, yum, from source, etc.):
.deb
Describe the bug:
Try to export a saved search from a dashboard as CSV. The CSV is correct but the format of the @timestamp is not OK for my customer because excel does not accept 2020-01-21T07:52:51.000Z which is the format I get (ISO8601).
I tried to change the format in the General Settings / Date format without effect.
The @timestamp should apply the Date format or there should be a way to specify the export format
Steps to reproduce:
2020-01-21T07:52:51.000Z
YYYY-MM-DD HH:mm
Expected behavior:
The @timestamp should be in the
YYYY-MM-DD HH:mm
format in the exported CSVScreenshots (if relevant):
Errors in browser console (if relevant):
Provide logs and/or server output (if relevant):
Any additional context:
The text was updated successfully, but these errors were encountered: