Skip to content

Conversation

@tbregolin
Copy link
Contributor

This mirrors the behaviour of the Alertmanager UI, which converts the
inputed string into UTC. This is better because otherwise you get mixed
timezones in the string representations when you query the
/api/v2/silences endpoint, for instance. It is also more "correct"
because Alertmanager uses UTC for presenting and updating dates, and so
amtool should do the same.

This mirrors the behaviour of the Alertmanager UI, which converts the
inputed string into UTC. This is better because otherwise you get mixed
timezones in the string representations when you query the
/api/v2/silences endpoint, for instance. It is also more "correct"
because Alertmanager uses UTC for presenting and updating dates, and so
amtool should do the same.

Signed-off-by: Thomas Bregolin <tbregolin@cloudflare.com>
@simonpasquier
Copy link
Member

I'm confused how it changes anything to the current implementation. AFAICT this PR would only change the representation of what's being sent to the API.

@stale stale bot added the stale label Mar 29, 2021
@roidelapluie
Copy link
Member

it means that the bug is that we do not convert the date when returning it to the user.

@stale stale bot removed the stale label Aug 4, 2021
@stale stale bot added the stale label Oct 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants