It would be usefull that the system.alarm.queryJournal return the id (AutoIncremental PK of the alarm_events table) for sorting the data according the insert order, if a datetime with millisecond is not possible.
(getId return the eventid).
system.alarm.queryJournal Returns :
List - A list of matching AlarmEvent objects. AlarmEvent objects can be examined with getAckData, getActiveData, getClearedData, getCount, getDisplayPath, getDisplayPathOrSource, getId, getLastEventState, getName, getNotes, getOrDefault, getOrElse, getPriority, getProperties, getRawValueMap, getSource, getState, getValues, isAcked, isCleared, isExtended, isInherited, and isShelved.
I'm having this same issue in v8.1.28. When listing events in the Alarm Journal component in Vision, ordering by Event Time isn't precise enough to show the exact order in which events happened. When an alarm is raised in the same second it's cleared, like I just encountered, the raised event is sometimes ordered after the cleared event, making it look like the alarm is still active, leading to confusion. I'm using MySQL v8.0 and millisecond precision DATETIME columns are supported (since v5.6+ it looks like).
Has there been any movement on this? This is an issue I'd prefer not to have to develop a workaround for, if that's even possible.
I was working on something about alarming and hit that same issue. I figured out that the problem come from the fact that Ignition create the column as DATETIME. But to be able to see the fractional part it has to be a DATETIME(3).
Running this querry:
ALTER TABLE alarm_events MODIFY eventtime DATETIME(3)
fixed the problem