[🐛 Bug]: in UI timeline panel, date variable alert.lastReceived show date in UTC

[00041275]

Describe the bug
in UI timeline panel, date variable alert.lastReceived show date in UTC, but panel alert history show local date.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://platform.keephq.dev/
2. Simulate alert
3. Click to alert in alert page
4. in dialog panel go to timeline (check date with your local date)

Screenshots

[dosubot]

Hey @00041275! I'm here to help you with any bugs, questions, or contributions you have. Let's work together to solve this issue!

The issue you're experiencing with the alert.lastReceived date being displayed in UTC in the UI timeline panel, while the alert history shows the local date, is likely due to how the dates are formatted and displayed in different parts of the application.

In the UI timeline panel, the alert.lastReceived date is displayed using the TimeAgo component, which shows the time elapsed since the date in a human-readable format, such as "5 minutes ago" ^[1]. This might not account for local timezone adjustments.

For the alert history, the formatTimestamp function is used to convert UTC dates to local dates. This function creates a Date object from the timestamp and returns it as a localized string using toLocaleString(), which respects the user's local timezone settings ^[1].

To ensure consistency, you might want to check if the TimeAgo component or the logic in the timeline panel can be adjusted to also respect local timezone settings.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[talboren]

Describe the bug in UI timeline panel, date variable alert.lastReceived show date in UTC, but panel alert history show local date.

To Reproduce Steps to reproduce the behavior:

1. Go to https://platform.keephq.dev/
2. Simulate alert
3. Click to alert in alert page
4. in dialog panel go to timeline (check date with your local date)

Screenshots

Thank you for another great issue :) What would you prefer more - I guess the locale time makes more sense, correct me if I'm wrong.

[00041275]

Thank you for another great issue :) What would you prefer more - I guess the locale time makes more sense, correct me if I'm wrong.

Yes of course, locale time :)

UI is my weak point, but I can report a problem. In general, I see a problem in dates on the backend and frontend (somewhere UTC, somewhere just a date (local)). Of course, the date received in KEEP for the alert part should be in UTC, so as not to depend on the time zone change. But for example, keep/api/core/db.py, function update_provider_last_pull_time, line provider.last_pull_time = datetime.now(tz=timezone.utc) - for some obvious reason, instead of UTC date in the DB, I get local time. After looking at some cases, I removed timezone "datetime.now()" and everything worked. In simple terms, 4 parts are not clear:

1. what timezone should be on the server/container/application/DB (deployment doc haven't info)
2. why datetime.now(tz=timezone.utc) and datetime.now() and field.Datetime and time.time() with the server in UTC give different effects? why are different approaches used?
3. how should date fields work in UTC or in local time? and is it worth hanging datetime.now(tz=timezone.utc) on everything in this case
4. UI why when receiving data from the server the data is not immediately localized and formatted, but is done at the component level, which leads to autonomy and duplication of code.