Clarify time zone in Analytics > Filter Logs screens

[GUI]

In the Analytics > Filter Logs screen, the time zone of the data can be ambiguous:

We show an explicit time zone in the chart data (when viewing by minute or hour), which is always east coast. However, the data in the table underneath is always displayed in your browser local time, but it doesn't clarify what time zone the data is in. If you download the CSV data from this same page, the CSV data is returned in UTC, but again, without clarifying what time zone the data is in.

I'd propose making the following changes:

1. Add a time zone specifier to the dates shown in the table so it's clear what time zone this is in.
2. Optional: Should we consider hard-coding the table data so it's always shown in ET to match the charts above? Or alternatively, should we change the chart so it shows data in the local time instead? Updating the chart gets perhaps a bit wonky, since if you're viewing the daily, weekly, or monthly charts, those will always be hard-coded to end the days in ET. So this would then make the hourly/minutely charts inconsistent with when the daily charts end. But maybe having the mixed time zones between the chart and table are fine as long as we're explicitly showing them, so maybe doing nothing here is simplest. But I could go either way on this.
3. Update the CSV time output format to include time zone. This original format was picked so Excel would pick it up as a time field, but I'm maybe more inclined to just format all of our CSVs in ISO8601 UTC format so it's more explicit and easier to parse programatically. This could be a backwards incompatible change for anyone with automated processes on the CSV downloads, but I suspect most of the automated things are built using the JSON endpoints instead, so I think we could get away with changing this.

[jtmkrueger]

Regarding 2. I think making both the chart and table both show ET would be a compromise between having to detect user timezone and leaving them different. But defer to you @GUI!

[GUI]

@jtmkrueger, sounds good to me! That probably is the simplest option to implement and keep things consistent with the charts in all cases. And non-ET people I think are plenty use to eastern time, as long as we explicitly include the time zone specifier. For a few quick tips on where some of this code is located:

• The table rendering this column: https://github.com/NatLabRockies/api-umbrella/blob/eac5a7c32d971c7f193179da3469d3cbd561d590/src/api-umbrella/admin-ui/app/components/stats/logs/results-table.js#L61
• The underlying helper responsible for showing the time (so I think if we add a time zone bit to this output, that would help address 1, but less sure about where we tune moment-timezone to change timezones if we want to force things to ET): https://github.com/NatLabRockies/api-umbrella/blob/eac5a7c32d971c7f193179da3469d3cbd561d590/src/api-umbrella/admin-ui/app/utils/data-tables-helpers.js#L84-L90
• For the CSV, I think these are the helpers used any place we're returning a CSV time: https://github.com/NatLabRockies/api-umbrella/blob/eac5a7c32d971c7f193179da3469d3cbd561d590/src/api-umbrella/utils/time.lua#L77-L84, https://github.com/NatLabRockies/api-umbrella/blob/eac5a7c32d971c7f193179da3469d3cbd561d590/src/api-umbrella/utils/time.lua#L113-L129 While we could maybe track down where some of these are used and change them to use the input ISO8601 strings directly (which would be a bit more efficient than re-parsing each ISO8601 string to then just output in ISO8601 again), since the input formats may be different (some of them have milliseconds and others don't, some may specify timezones with an offset instead of Z), I wonder if we just keep all of these *csv helpers in place and change them to call date:format(format_iso8601) or date:format(format_iso8601_ms) as appropriate. But open to other ideas here if you find stuff after digging in.