# Machine states durations grouped by time in SQL best options

**URL:** <https://forum.inductiveautomation.com/t/machine-states-durations-grouped-by-time-in-sql-best-options/86822>\
**Category:** General Discussion\
**Created:** [March 5, 2024, 12:57pm UTC](https://forum.inductiveautomation.com/t/machine-states-durations-grouped-by-time-in-sql-best-options/86822 "2024-03-05T12:57:11Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![Zach\_Larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zach_larson/32/54388_2.png) [@Zach\_Larson](https://forum.inductiveautomation.com/u/Zach_Larson)\
**Post date:** [March 5, 2024, 9:00pm UTC](https://forum.inductiveautomation.com/t/machine-states-durations-grouped-by-time-in-sql-best-options/86822/8 "2024-03-05T21:00:54Z")

</div>

That is a great question.  
Here is the answer as best that I understand it.

The datetime type was not set datetime2 from the start on the gateway.  
The gateway is setup EST.  
The table for states has timestamps in UTC.

I don't know if we can change the datetime type to datetime2 now.  
I think it will break things.

I don't know enough about setting the datetime type to datetime2 to know for sure that I understand this.

I know that when I checked to see what the datetime type was set to currently, I think it was set to datetime. I think it has been that way a long time. I don't know how many things switching to datetime2 would impact.

I think this applied to me:

> [@Transaction group, UTC tstamp when the Gateway is EST](https://forum.inductiveautomation.com/t/transaction-group-utc-tstamp-when-the-gateway-is-est/85972/2):
>
> Of course, if your transaction groups are storing into tables whose `t_stamp` columns are discarding timezone information, you may be screwed.

Or this one:

> [@Microsoft SQL Server DATETIMEOFFSET](https://forum.inductiveautomation.com/t/microsoft-sql-server-datetimeoffset/29761/27):
>
> Yes, it can be a big deal for a system in production. It is best to get the column types correct up front. (For a corporation that has facilities spanning multiple time zones, the plain MS SQL Server `datetime` column type is a terrible design choice. Your client's DB admins should be chastized.)

I think one way or another, I am kind of stuck.  
I don't know for sure if nothing will break.

I do know that the Gateway has been running a long time without the datetime type being switched to datetime2.  
I don't fully understand the implications of the change.

Maybe you can help me understand it more and if I am stuck or if it is a simple change. I think it sounds like the change would break things.

Am I stuck?

---

_[View the full topic](https://forum.inductiveautomation.com/t/machine-states-durations-grouped-by-time-in-sql-best-options/86822)._