# Query journal alarm, no millisecond, sorting issue **URL:** \ **Category:** Ignition\ **Created:** [March 19, 2018, 8:03pm UTC](https://forum.inductiveautomation.com/t/query-journal-alarm-no-millisecond-sorting-issue/17422 "2018-03-19T20:03:50Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\ **Post date:** [March 19, 2018, 8:03pm UTC](https://forum.inductiveautomation.com/t/query-journal-alarm-no-millisecond-sorting-issue/17422/1 "2018-03-19T20:03:50Z")
I query historical alarm from the journal with **system.alarm.queryJournal.** In my case data are stored in **MYSQL**. if the alarm is active and cleared in the same second when I sort my result with event time, the chronological order can be wrong because the event timetamp has no millisecond. The alarm journal table seem to have an incremental id which could be perhaps used to give the chronological order of event but this id is not returned by the system.alarm.queryJournal result ??? **system.alarm.queryJournal.** return a list of event, but is there a sort order ? Since mysql 5.6+, DATAETIME(3) enable to store datetime with milliseconds. It will be usefull to update alarm journal creating script for support of millisecond. > [@Timestamp milliseconds in MySQL](http://forum.inductiveautomation.com/t/timestamp-milliseconds-in-mysql/647): > > I’m reading that MySQL does not support fractional seconds in the Timestamp data type. Is this true? Is there any guidance you can offer to work around this shortcoming to display fractional second data in a chart? Thanks. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 19, 2018, 11:25pm UTC](https://forum.inductiveautomation.com/t/query-journal-alarm-no-millisecond-sorting-issue/17422/2 "2018-03-19T23:25:15Z")
Heh, I knew I dodged a lot of bullets over the past twelve years by choosing PostgreSQL. I just didn’t know about all of them (probably still don’t). ---
**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\ **Post date:** [March 21, 2018, 5:07pm UTC](https://forum.inductiveautomation.com/t/query-journal-alarm-no-millisecond-sorting-issue/17422/3 "2018-03-21T17:07:49Z")
@KathyApplebaum, 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. ---
**Author:** ![KathyApplebaum](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kathyapplebaum/32/7261_2.png) [@KathyApplebaum](https://forum.inductiveautomation.com/u/KathyApplebaum)\ **Post date:** [March 21, 2018, 5:35pm UTC](https://forum.inductiveautomation.com/t/query-journal-alarm-no-millisecond-sorting-issue/17422/4 "2018-03-21T17:35:48Z")
I _think_ they’re reworking some of the alarm journal stuff in Ignition 8? If so, hopefully something like that would get in. I’m not on that team, so I have no idea. ---
**Author:** ![Brandon\_Peterson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/brandon_peterson/32/32960_2.png) [@Brandon\_Peterson](https://forum.inductiveautomation.com/u/Brandon_Peterson)\ **Post date:** [November 28, 2023, 4:35pm UTC](https://forum.inductiveautomation.com/t/query-journal-alarm-no-millisecond-sorting-issue/17422/5 "2023-11-28T16:35:24Z")
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. ---
**Author:** ![Samuel\_Langlois](https://avatars.discourse-cdn.com/v4/letter/s/6bbea6/32.png) [@Samuel\_Langlois](https://forum.inductiveautomation.com/u/Samuel_Langlois)\ **Post date:** [December 10, 2023, 7:49pm UTC](https://forum.inductiveautomation.com/t/query-journal-alarm-no-millisecond-sorting-issue/17422/6 "2023-12-10T19:49:08Z")
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