We are trying to understand when an actual event occurred when our monitoring agents kick off an event. The alert email generated is reporting the Event Time in UTC time, not the local time of the agent machine, not the VSA time preference selection, but almost always in UTC time; which when looking quickly can be confusing. Sometimes the time is so bizzare, we cannot determine where the email got that time other than to speculate that the variable for <et> is loaded with some strange number.
It's been suggested to change the email format for Event Time to match the <ata> time which is the time the Agent Alarm Time. That time is when the email was sent which is usually after the procedure was run and well after the event actual occurred. Changing the Event Time to match the Agent Alarm Time is distorting the information greatly and in our opinion is a bad idea. We also noticed based on our VSA moment in time burden, the Alert could be off by many minutes thus making the event time even more distorted.
Why can't the variables <et> and <at> match the system preferences time selection?
I understand where you're coming from and can see how this would be really useful information. Addressing the specific question you've presented (and not wanting to negate the concern as it stands), the System > Preferences cannot be used in an email alert because the System > Preferences config is user-specific. Each VSA user can configure his or her own time display option, and those do not carry over to other VSA users. When the email is sent, the system is sending the email, so identifying which user's preference to use would lead to misleading timestamps. If you didn't know which user's preferences were being used, you would have no way to determine that offset.
Time is very complex - there are several variables including the KServer time, the agent time, the admin time, the browser time (which is usually the same as the admin time, but not always), then mix in various time zone offsets, Daylight Saving Time (with no globally standardized calendar or adoption), and the whole concept of time becomes challenging to manage programmatically. Because of this, time is stored in the database in UTC. When a schedule is created, the time is converted to UTC, and that is the time written to the appropriate fields in the db. Using a standardized time for all time-related data stored in the database ensures the local date/time can be appropriately calculated because you know exactly what time something occurred (or is scheduled to occur) based on the UTC time. It does require some calculations to determine local time; however, if some time functions were stored in UTC and others in KServer time, doing those calculations accurately becomes a challenge.
I don't believe there is an existing function which would convert a UTC timestamp into a configurable-local timetamp. Perhaps a new data key could be developed to provide more agent-time-specific information. Changing any time-related function is a substantial undertaking that requires significant planning and testing.
I do see a Feature Request (FR) about coordinating alert time to agent time (kaseya.zendesk.com/.../40051386) and would encourage anyone who would like to see this change to "like" this request by clicking the "Me Too!" button at the bottom of the FR. There are currently only five 'likes' for this particular request. Voting for the FR is the best way to demonstrate demand, and demand is a key component to evaluation of the requests for possible inclusion in future releases. Feasibility and functionality are also important considerations, but demand is also used in the evaluation process.
Paragraph 1 - Got IT and agree. I think I am not being clear. The Event Time is logged at the agent, not the server and the variable <et> (Event Time of a logged System Event) or <at> (Alert Time of that local machine event) should be loaded with that time from the event log on the agent machine. This is not a server time issue or a scheduling issue but rather how that local agent machine recorded the time of the event.
Paragraph 2 - Got IT and agree again, but the <et> or <at> time should not be used by the VSA for any purpose as it is just informational coming from the event log on the local agent machine.
Paragraph 4 - Got IT but don't see why a FR is required as we don't want to convert alert time to agent time. Just pass the information from the event log as is. After all Event Time is only relevant to the local machine and as I said before is purely informational. I believe many do not understand how the variables are used in email notifications and so are more unaware of this shortcoming in the product database, which is why you don't have more MSP's discussing and asking for this to be "fixed".
Thank you for the very long explanation, but I need to understand why we you are converting a logged event on a local machine. That time should be maintained and unchanged to preserve historical value.
The time is read from the event log and sent in UTC as each agent can belong to a different time zone and becomes problematic when trying to calculate against all of these different time zones and move time zones.
(IST, MST, EST, PST, Traveling to different time zone areas, etc, etc.)
This is not a shortcoming of the database but a way to maintain a standard time all over the world and calculate thereafter.
Below is an example using <ata> for Alarm Time and <et> for Event Time:
What I usually recommend is making the format email a friendlier/easier to read format.
Here is an example of how I modify the format email option to clearly understand the times:
Ultimately, as Brande Schweitzer_ mentioned this is a Feature Request as a new data key is desired to display the Event Times in a specific hardcoded timezone.