Metrics reported in UTC time with timezones should be displayed in local -or- UTC

[poswald]

Ideally if metrics are recorded with timezone information, it's best to default charts to the user's local timezone (via the browser) but allow the dates and charts to toggle to UTC. You want text at the top of the page that shows something like:

All times are in: JST (show in UTC)

Metrics services like Datadog do this well.

[ks888]

Thank you for your suggestion. That's interesting, but I'm not very sure why the UTC view is useful. For the monitoring services like Datadog, that will be useful as the application's logs may be recorded in UTC and a developer may compare the charts with those logs.

Can you tell me a little more about the use cases the feature is useful?

[poswald]

Sorry, totally missed your reply here. The reason this is useful is because when dealing with dates/times in international contexts, it's best to be explicit so people aren't confused. If you have users in different parts of the world its pretty much a requirement.

For instance events happen at a particular timestamp which gives us a strict point in time that something happened. So for instance an event that happened at 2018-04-01T01:00:00+09:00 would be 1am in Tokyo.

When viewing charts or the list of Incidents and they are shown under a calendar date of "Apr 01, 2018" it is unclear if that means the event happened on April 1st in UTC or in my browser's locale because it's not stated anywhere:

For instance in python:

In [1]: import datetime
    ...: import pytz
In [2]: japan_tz = pytz.timezone("Asia/Tokyo")
    ...: new_york_tz = pytz.timezone("America/New_York")
In [3]: now = datetime.datetime(2018, 4, 1, 1, 0, tzinfo=japan_tz) # 1 am on April 1
    ...: now.isoformat()
Out[3]: '2018-04-01T01:00:00+09:00'
In [4]: new_york_tz.normalize(now.astimezone(new_york_tz)).isoformat()
Out[4]: '2018-03-31T12:00:00-04:00'

Note that the date is now shown as March 31st because when the event happened (from your perspective) was a different calendar date depending on where on the earth you were. This is why it's pretty important to at a minimum state what timezone the dates are being displayed in somewhere on the page.

The reason Datadog's ability to change the current viewing context is as you say: it's nice to be able to switch when comparing event log files in UTC to the status board.

[ks888]

I see, thank you for your clear explanation.

I will add the text like All times are in: [timezone] at the top of page soon. Then add the UTC toggle button later. Of course it's great if you have a chance to contribute the code!

[ks888]

I quickly add the time zone message at the top of page, but now the page looks very messy.

The history page:

The incident report page:

Is there any better design idea?

[ks888]

I temporarily remove this issue from the next milestone (v0.6.2) due to this comment.

[poswald]

The location you had in the header works. I'd maybe put it here (ignore the style color):

Thanks for the fix to issue #112... I think it appears to be working correctly but there's still something a bit odd about the data in that it's not clear that the chart range is correct. Is it the case that currently dates/times are displayed in the timezone of the status page viewer's browser locale?

[danwhitston]

Hullo! Side note here, but in the UK we're currently on BST, which is one hour ahead of UTC. All of the metrics are showing graphs with UTC timestamps (because that's what they're stored as on CloudWatch. We can't really change logging times for the summer), but there's no way of indicating that they're UTC and thus out by an hour, nor to change displayed times to account for user's timezone. So the vast majority of users are just going to assume that metrics are an hour out of date.

(Also, a side note: thanks for writing this! It's super impressive and a lot less painful than paying £80 / month for something that probably won't see much use most of the time)