AKHQ must handle datetime with time zone consistently everywhere

[wnleao]

The way AKHQ handles datetime with time zones must be coherent by using the same time zone every place it handles datetime on the UI (e.g. when presenting dates and when handling timestamp selection).

We suggest that AKHQ should use UTC by default and in a future work the user could define a different time zone in the settings.

Topic filter timestamp

AKHQ should also be explicit about which timezone is being used to represent the date when selecting the timestamp. For instance, on the image below, the Date columns show the date using Zulu, but the javascript component is using the browser’s timezone to convert the selected timestamp and filter the data.

Consumer group update offsets

When updating offsets (see image below), it should be explicit to the user which time zone is going to be used (UTC by default).

When one selects a date and time, AKHQ is using in the request the same provided timestamp as UTC (see image below), which is the expected behavior.

We suggest that the Timestamp label should be “Timestamp (UTC)” or the field value should append the suffix like “08-03-2023 10:08 Z” or “08-03-2023 10:08 +00:00”.

Produce to topic

When producing a message to a topic, currently, the provided timestamp is converted to UTC without an explicit representation on the UI. I'm working with CET here (1 hour ahead of UTC).

One can confirm that the request payload is using the UTC on the image below.

We suggest that the timestamp should be handled as UTC and:

• the timestamp label should be “Timestamp (UTC)”; or
• the field value should append the suffix like “08-03-2023 10:08 Z” or “08-03-2023 10:08 +00:00”.

Let us (@flysen and I) know if you think that this is something worth pursuing and we would be more than glad to help.