[FEATURE] Support time zone as a query parameter for queries

Is your feature request related to a problem?

1. No timezone info in response, By default, convert value using UTC timezone

source=test00001

###
  "datarows": [
    [
      "2025-05-01 13:49:00"
    ],
    [
      "2025-05-01 14:49:00"
    ],
    [
      "2025-05-01 15:49:00"
    ]
  ]

2. Inconsistent behavior when displaying timestamps. When I run a query in PST on 2025-05-02 11:58:44, the mydate field is displayed in UTC, while current_timestamp() is displayed in PST.

source=test00001 | where mydate > timestamp('2025-05-01 13:50:00') | eval cur=current_timestamp()

  "datarows": [
    [
      "2025-05-01 14:49:00",
      "2025-05-02 11:58:44.582"
    ],
    [
      "2025-05-01 15:49:00",
      "2025-05-02 11:58:44.582"
    ]
  ]

What solution would you like?

• Support timezone as query paramater
• When parsing timestamps without explicit timezone information (e.g., '2025-05-01 10:30:00'), interprets the string as a local time in the session timezone and converts it to UTC.

SELECT to_timestamp('2025-05-01 10:30:00')=to_timestamp('2025-05-01T10:30:00.000Z'), to_timestamp('2025-05-01T10:30:00.000Z')=to_timestamp('2025-05-01T10:30:00.000Z'), to_timestamp('2025-05-01 10:30:00 America/Los_Angeles')=to_timestamp('2025-05-01T10:30:00.000Z');

SET TIME ZONE '-00:00';
true	true	false

SET TIME ZONE '-07:00';
false	true	false

• When timestamps are displayed (e.g., in query results), converts the stored UTC value back to the session timezone for readability.
• Functions like current_timestamp(), from_unixtime(), and to_timestamp() use the session timezone to interpret or generate timestamps.
• Operations like hour() are computed based on the session timezone.

SELECT hour(to_timestamp('2025-05-01 10:30:00')), hour(to_timestamp('2025-05-01T10:30:00.000Z')), hour(to_timestamp('2025-05-01 10:30:00 America/Los_Angeles'));

SET TIME ZONE '-00:00';
10	10	17

SET TIME ZONE '-07:00';
10	3	10

What alternatives have you considered?
A clear and concise description of any alternative solutions or features you've considered.

Do you have any additional context?

• data

###
POST {{baseUrl}}/test00001/_doc
Content-Type: application/x-ndjson

{
  "mydate" : "2025-05-01T05:49:00-08:00"
}

###
POST {{baseUrl}}/test00001/_doc
Content-Type: application/x-ndjson

{
  "mydate" : "2025-05-01T06:49:00-08:00"
}

###
POST {{baseUrl}}/test00001/_doc
Content-Type: application/x-ndjson

{
  "mydate" : "2025-05-01T07:49:00-08:00"
}

The payload names no source files, tests, or entry points; start by tracing how query parameters and session time zones reach timestamp parsing, display, and time functions. Done means the requested timezone parameter consistently affects parsing, results, timestamp functions, and hour() behavior as shown in the examples.