# SQL Queries and Time Differences

**URL:** <https://forum.inductiveautomation.com/t/sql-queries-and-time-differences/99392>\
**Category:** General Discussion\
**Created:** [December 4, 2024, 2:05am UTC](https://forum.inductiveautomation.com/t/sql-queries-and-time-differences/99392 "2024-12-04T02:05:02Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Matrix\_Engineering](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/matrix_engineering/32/19781_2.png) [@Matrix\_Engineering](https://forum.inductiveautomation.com/u/Matrix_Engineering)\
**Post date:** [December 8, 2024, 11:42am UTC](https://forum.inductiveautomation.com/t/sql-queries-and-time-differences/99392/2 "2024-12-08T11:42:08Z")

</div>

> [@SQL Server store datetime object with time zone](https://forum.inductiveautomation.com/t/sql-server-store-datetime-object-with-time-zone/49319/2):
>
> Two suggestions: Don’t use jython’s datetime. Use java.util.Date and related types–that’s what Ignition passes around. Set MS SQL Server to use UTC and the server it runs on to UTC. That is the only way to have flawless date/time/timezone support in Ignition. Java’s datetime type is fundamentally built in milliseconds UTC (including serialization when passed over a network) with conversions to and from local time zones as needed. This allows clients and gateways to work with the same…

> Microsoft SQL has a DATETIME column type that does not store time zone information. It also has a DATETIME2 column type that **does** store the origin timezone.

---

_[View the full topic](https://forum.inductiveautomation.com/t/sql-queries-and-time-differences/99392)._
