# Alarm timezone stored in database **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [February 24, 2023, 12:33pm UTC](https://forum.inductiveautomation.com/t/alarm-timezone-stored-in-database/70277 "2023-02-24T12:33:41Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\ **Post date:** [February 24, 2023, 12:33pm UTC](https://forum.inductiveautomation.com/t/alarm-timezone-stored-in-database/70277/1 "2023-02-24T12:33:41Z")
Hi, We are storing alarms in an alarm journal. The alarm journal table is auto created with the field 'eventtime' being a timestamp without timezone, just regular Ignition. My gateway time is set at the physical timezone of the server, so not utc. The project timezone is set to client timezone. My issue: When an alarm is triggered and stored in the alarm journal, it's stored in the database not in utc time, but in the gateway time, even though the column is a timestamp without timezone. What is best practice here? Should the gateway be set to utc time to fix this? Or am I doing something wrong? ---
**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:** [February 24, 2023, 1:22pm UTC](https://forum.inductiveautomation.com/t/alarm-timezone-stored-in-database/70277/2 "2023-02-24T13:22:08Z")
That's what "timestamp without timezone" means--it implies the timezone of the database connection, which is initiated by the gateway. Ignition doesn't use any non-timezone datetimes in its code, but `java.util.Date` and friends, which are UTC milliseconds under the hood. That is, they specify a unique moment in time without regard to timezone, and are thereafter converted to and from local timezones as needed. That means that all datetimes pulled from a database that don't have timezone will be assumed to be in the gateway's timezone and the UTC millis established from that. No, there's no way to change this behavior. In other words, `timestamptz` is almost **always** the correct choice in Ignition. FWIW, in PostgreSQL, that column type consumes exactly the same space as the `timestamp` type, but the 64-bit microseconds they use under the hood is interpreted differently in the DB--UTC versus localtime. ---
**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:** [February 24, 2023, 1:25pm UTC](https://forum.inductiveautomation.com/t/alarm-timezone-stored-in-database/70277/3 "2023-02-24T13:25:07Z")
Some databases (MS SQL Server) have timestamptz-ish column types (datetime2 in MS SQL) that don't play nicely with Ignition, usually because they are overspecified for a unique instant in time. With such DBs, you **should** set the gateway to UTC so the timestamp type works correctly (like your case). ---
**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\ **Post date:** [February 24, 2023, 1:40pm UTC](https://forum.inductiveautomation.com/t/alarm-timezone-stored-in-database/70277/4 "2023-02-24T13:40:47Z")
Thanks Phil for you answer. It left me a bit confused though... > [@pturmel](#): > > That's what "timestamp without timezone" means What do you mean with 'That'? I said multiple things... > [@pturmel](#): > > Ignition doesn't use any non-timezone datetimes in its code, but `java.util.Date` and friends, which are UTC milliseconds under the hood Then why is the date stored in the database wrong? I want it to be utc in the database, but it's not. > [@pturmel](#): > > and are thereafter converted to and from local timezones as needed. Is thereafter when you present the date to a user? > [@pturmel](#): > > That means that all datetimes pulled from a database that don't have timezone will be assumed to be in the gateway's timezone and the UTC millis established from that. Yes, retrieving date from the database seems very correct. I only have troubles with storing dates. > [@pturmel](#): > > In other words, `timestamptz` is almost **always** the correct choice in Ignition. FWIW, in PostgreSQL, that column type consumes exactly the same space as the `timestamp` type, but the 64-bit microseconds they use under the hood is interpreted differently in the DB--UTC versus localtime. I lost you here. Do you mean I should change the timestamp in my alarm journal tables? ---
**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:** [February 24, 2023, 1:54pm UTC](https://forum.inductiveautomation.com/t/alarm-timezone-stored-in-database/70277/5 "2023-02-24T13:54:20Z")
> [@louagejasper](#): > > What do you mean with 'That'? "That" means the original timestamps (UTC millis under the hood) will be converted to DB connection's timezone for the localtime conversion and stored that way. Then when queried, the localtime pulled from the DB is again converted to UTC using the DB connection's timezone. Just because you are storing them without a timezone doesn't mean Ignition can use them without a timezone. It's just implied. > [@louagejasper](#): > > I want it to be utc in the database, but it's not. You chose a column type that is always localtime. `timestamptz` is always UTC. > [@louagejasper](#): > > Is thereafter when you present the date to a user? Yes. Ignition doesn't use any localtime objects. So your "localtime" is converted to a UTC-based object when retrieved from the DB (using gateway TZ), dispatched where needed in Ignition in that form, then converted to the client timezone for display. > [@louagejasper](#): > > I only have troubles with storing dates. No, it is doing precisely what you asked. Your mistake is assuming that Ignition can move timestamps around in any localtime format. > [@louagejasper](#): > > Do you mean I should change the timestamp in my alarm journal tables? I recommend that to prevent ambiguity, particularly if the database is accessed by any non-Ignition means that have a different connection timezone. Your mistake is thinking a localtime retrieved from a DB is treated any differently than a UTC-based timestamp retrieved from your DB. They are all converted to a UTC-based format at the point of retrieval. ---
**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\ **Post date:** [February 24, 2023, 2:06pm UTC](https://forum.inductiveautomation.com/t/alarm-timezone-stored-in-database/70277/6 "2023-02-24T14:06:19Z")
Okay, So if I understand you correctly, Ignition auto-create-table for the alarm journal isn't serving me well and I should change the data type of that column so it has a timestamp with timezone data type. I will do some tests with that.