SDT UIv4 after winter time
We are experiencing a very weird bug with the SDT function in UIv4. When selecting any date before “winter time”start, it works just fine (as long as we use 12H format…Why can’t we choose between 12 and 24?). Also UTC shouldn’t be affected by winter time. Here you see that we can easily put an SDT as expected When trying to put an SDT after winter time starts (29th of October) we are unable to directly write the time, like we did in the gif above. When trying to write 10:00 it just increases the number until it changes the date and we have to go back to select the right date. Also we get an error saying that the format must be HH:MM, which it clearly is but we are still not allowed to put an SDT on it in UIv4. All of this works just fine in UIv3.86Views1like2CommentsAnsible Time Zone Support
Hello! I currently use Ansible to schedule a task which updates Windows on the servers we manage, roughly 300 in Azure. These servers are spread throughout the world in many different time zones. In my playbooks for configuring the “patching task”, I would like to set a SDT in Logic Monitor. Currently there is no “time zone” setting with the Logic Monitor Ansible module. I’m sure I could get around this by doing some sort of math on the date / time within the SDT playbook. Does anyone do anything like this? Some other notes about our setup: We have a mix of Windows Server 2022 and Windows 11 VMs Azure Automation / Update Management does not support Windows 11 VMs Time zones on the servers are local to the region they are deployed in Our patching schedule is … staging 1 week after “patch Tuesday” production 2 weeks after “patch Tuesday” Because of this, reoccurring SDTs need to be reconfigured twice a year, say when the first of the month falls on a Wednesday Sometimes patching needs to be rerun, so it would be nice to SDT the servers / device groups whenever needed Thanks! Jerry37Views3likes0CommentsSDT Duration calculation off
It’s hard to know if this is an issue with v4 or if it was happening the whole time. However, it’s easy to see that it’s wrong now. When we set permanent SDT on something, we typically just change the first digit of the year from a 2 to a 3. Meaning, we change the SDT so it ends 1000 years in the future. In the old UI, it would calculate the duration of the SDT and show it in minutes and seconds. The new UI adds years, months, days, and minutes (at least). For one SDT i just set from 2023-03-23 02:11 PM EDT to 3023-03-23 02:11 PM, the new UI shows 1000 years, 8 months, 2 days, and 59 minutes. Unless there’s going to be a new ceasar and a new calendar (possible), I don’t know why it has anything other than 1000 years exactly. Where did the 8 months, 2 days, and 59 minutes come from? For reference the old UI shows 365242 days 59 minutes. I get the 365000 days, +/- a few for leap day anomalies. But even in the old UI, where did the 59 minutes come from?34Views1like0Comments