[BUG]

[jpride15]

Describe the bug

A clear and concise description of what the bug is.

When I search for any transcript but for an example when I search the contactID: 4033ec5e-b797-473d-9b3a-1c3bdec5c16a it shows that in Optics the time and date is Oct 18, 2023 @ 22:33:57.000, however when I download the CSV and upload it to Google Sheets it shows that the time and date for the same contactID is Oct 19, 2023 @ 02:33:57.000, adding 4 hours to the time that the call took place. I saw that there was an option in Optics to change the timezone within the Advanced Search, searching for timezone, it shows the default is "Browser" but when I switch it to "America/New York" a 403 error appears, preventing me from making the change. I'm not sure if adjusting the timezone in Optics would assist with this issue but I am interested in learning more as to why the is happening when I download the data to a CSV and how I'm able to avoid this inconsistency of times in the future. Thank you so much for your help!

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Advanced Search'
2. Click on 'timezone' (or search for timezone at top)
3. Scroll down to select 'America/New York'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

I expected the timezone change to be completed and then once I download the transcript with the contactID: 4033ec5e-b797-473d-9b3a-1c3bdec5c16a to a CSV and upload it to Google Sheets it would have the same time and date as shown in Optics.

OpenSearch Version
Please list the version of OpenSearch being used.
v1.3.2

Dashboards Version
Please list the version of OpenSearch Dashboards being used.
unsure

Plugins

Please list all plugins currently enabled.

Screenshots

If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: [e.g. iOS]
• Browser and version [e.g. 22]

Additional context

Add any other context about the problem here.

[ananzh]

Hey @jpride15 thanks for opening this issue. The behavior you're observing is due to the time zone settings in OpenSearch Dashboards. When you save a timestamp without specifying a time zone, OpenSearch interprets it as UTC. I don't think this is a bug. Currently, I found one way working given your expectation. I will use Seattle Local Time (PST) with Time Zone (2023-11-12T12:00:00-08:00) as an example. When save the data, save it with time zone

PUT /timezone_test/_doc/1 
{  
    "timestamp": "2023-11-12T12:00:00-08:00", 
    "other_field": "value" 
}

The -08:00 indicates that the time is in Pacific Standard Time (PST), which is 8 hours behind UTC. Since the time is already in PST, there is no conversion needed when displaying it in OSD. The timestamp is displayed as Nov 12, 2023 @ 12:00:00.000 when downloaded in table vis, reflecting the local Seattle time. So what you save/add is the same as what you download.