v9.0.3 - Reports - What Am I actually Seeing when Time Zones Differ?

PDinCA

The Reports documentation doesn't mention anything about the date-time selector, the email scheduler, and the instance being measured, when it comes to mixed time zones.

The monitoring server is on Pacific Time; the 3 servers for THIS Report need are all on Eastern Time.

When I choose a "Day", ending at 00:00 hours using the dropdown, am I saying midnight EASTERN or midnight PACIFIC.  If it is Pacific - that's a hard FAIL.  If it is Eastern, kindly do several things (non-exhaustive list):

1. State clearly in the documentation the time zones being used.
2. When the report is being created, clearly show the time-zone of the instance chosen, both when showing the preview, and when choosing the date-time range.
3. Show the time zone on the Report.  If common to all instances, show it once.  If disparate time zones, (we have one customer with a set of database servers on PST, EST, EU-CST, China, and Japan) adjust to a common x-axis, and put the time zone in the legend.

Our customer wants to see these utilization reports on EASTERN Time, only, ever, and especially as we will emit the report on a business-day schedule.  They have every right to be perturbed by presentation of data in Pacific Time, where they have to on-the-fly adjust to Eastern.  

When my East Coast colleagues run the same report, what do they see?  Will they get a 3-hour adjustment?  And my South African colleagues - will they see a 9-hour adjustment? Or what?

I cannot even tell the customer, or my colleagues, just what that are seeing via the pdf, or will see if they open the SQM UI from a non-pacific time zone for this set of reports.

This is beyond unnecessary confusion if we cannot reliably see the exact same data from the same server, using the server's time...

Do explain, please.

Russell D

Hi @PDinCA ,

Sorry you didnt get a response earlier this ticket got missed for some reason. The reports are generated based on the date/time of the basemonitor machine. The reason for this is that otherwise, you have the downside of trying to infer a timezone. For example if the report covered servers in a number of timezones, what timezone would it be appropriate to use?

Instead, perhaps it would be better to be able to specify the timezone on the report e-mail time selector?

After some discussion we're going to look into how we can go about implementing your suggestions as we do feel this is sensible.

Hope this helps - sorry, no timeframes!

PDinCA

I commented on normalizing the time-line on the charts, and suffixing the time-zone in the legend.  That would be far preferable to having to state a single time zone for a multi-zone report.

There is no notion whatsoever of any "downside" involving "time-zone inference".  The timezone information is readily available from each server - please use it - no guesswork/inference needed.

As also noted, when the servers run on the same time-zone, there isn't a problem, except for the consumer to know what that timezone is - just show the server timezone on the report.

Irrespective of a User's timezone, always, and forever, only use the server time.  It is awful to expect us to use the repository timezone, or to put a repository in each time zone just to satisfy a reporting feature that ought, honestly, to be better at what it does than it is now!  (I give it a 2/10)

The auto-scheduling doesn't need a time-zone selector...  Use the server's time.  End of story.  End of confusion.  The Report for multiple zones would be the ONLY place a time-zone would be needed - give us a dropdown of those zones across the population of servers on the report, let us pick which one to set as "Zulu", and fire off the auto-report at that time of day, in that timezone. 

The time-zone math isn't difficult, except when DST/STD occurs just twice a year max, and I'm very aware of many of those nuances form timebie.com, having had the "joy" of understanding UTC-based maintenance date-times across the globe where these time-shifts occur.  Time-zone designation helps that, but admittedly, the fall-back day's measurements are a pithy problem...  But that's just one day a year.

All this is a tad moot, though, because despite setting up IIS per the instructions, I cannot get a single auto-scheduled report out, but on-demand "send test email" works just fine!

My hope is that the Report function will mature swiftly, but as you said "no timeframes", it will remain one of the least used and least useful features.  (Sure would like to able to email myself the Analysis page content... Exporting a csv and then having to make my own charts, when you already made them...  Why prevent pdf-ing the page and emailing?)