You may be right, @AndyW. I thought the JavaScript solution typically converted the user's time zone into the report suite time zone, but I could be wrong about that. I don't see the "user's clock could be off" as a statistically significant problem; the overwhelming majority of people are likely ot...

Thanks, @jaydge88! We will definitely keep you posted, and I promise to kick up some new discussions on the best ways to make this possible. 

Fair enough, @TimWilson! 

Hi @GilliganOnData2, I think we already do this. We don't show it directly over the data point, but it is in the legend. See screen shot: Is there something I am missing here? Is the lesson just that users may not think to look over there, so it should be closer to the data point itself? 

Thanks for the feedback, @GilliganOnData2. I don't know that we've discussed fonts per se, but we have definitely talked about giving you more control over things like color pallettes so that you can draw attention to certain data. Great suggestion to add to that list. 

I thought we did auto-save. @wbrandongeorge? 

Thanks for the reminder on this, @psilva! 

With all due respect, @jaydge88, things that seem easy from the outside often are not as simple as they appear. The biggest challenge with this request is that we do not force your project layout to respect traditional page boundaries. We have heard from many users that you do not want visualization...

Noted, @michael-jet, and thanks for the reminder. This is a good idea, and we will keep an eye on it. The workaround that you noted is still relevant, and if you or anyone else has this use case, we recommend passing hour of day into a prop or eVar so that it aggregates across days at the hour level...

These are all great points. Some thoughts: 1. For comparing hours of day across days, there's currently a bug (or perhaps bad design) related to the existence of the date in the rows when showing hour (as you pointed out). The result is that you can't really compare a single hour across days. That s...