I just upgraded to 11.5 (yeah I know...) and I am seeing odd behavior in the new alert database tables. I seems they are not using the local server time for the timestamp of when an alert occurred. Screenshots below of a volume alert that occurred shortly before 9:30 am today (3/23)
Both images show the same alert, but the "All Active Alerts" page in Orion seems to be automatically converting them back to the correct time. I use many custom SQL queries to report out on alert status and time is a critical component of them. As is stands, if an alert triggered at 11 pm tonight, my daily report of alerts triggered for today WOULD NOT show it since the database would stamp it as 3 am TOMORROW.
Is this by design, if so WHY?
We store time in DB in UTC.
You have to change your queries
I recommended use one of function from this page:
After changing timezone you will only change one number in function.
I recommended use this one:
--Purpose: To convert UTC to local US time accounting for DST
--Author: Patrick Slesicki
Simple change from ALTER nameoffunction to CREATE nameoffuction.
Yes, but the alert timestamps in previous versions were not on UTC, they were on local server time.
So now i have to manually update all of my SQL queries to subtract 4 hours from the timestamp? And this is only for the next 6 month until we Fall Back and then i have to do it again to subtract 5 hours? This was exactly why I all my server to Eastern time regardless of location.
Out of curiosity, what is your timezone and what is the timezone of the polling engine?
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.