# Gateway Timezones and Script function behavior

**URL:** <https://forum.inductiveautomation.com/t/gateway-timezones-and-script-function-behavior/107050>\
**Category:** Ignition\
**Tags:** scripting, perspective\
**Created:** [June 4, 2025, 7:55pm UTC](https://forum.inductiveautomation.com/t/gateway-timezones-and-script-function-behavior/107050 "2025-06-04T19:55:53Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**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:** [June 5, 2025, 1:52pm UTC](https://forum.inductiveautomation.com/t/gateway-timezones-and-script-function-behavior/107050/4 "2025-06-05T13:52:39Z")

</div>

> [@benjamin.nothwehr](#):
>
> I think what I really need

**NO**

Don't do arithmetic with dates to correct for time zones. `java.util.Date` objects are fundamentally UTC under the hood, representing a worldwide point in time, and trying to "adjust" them to correct for timezones simply makes them **incorrect**. If you pass incorrect timestamps to historian calls or other system functions, you will get **wrong answers**.

These objects are stringified in the timezone of the JVM that does the string conversion, and are created by string parsing in the timezone of the JVM that does the parsing.

If you want to stringify or parse in a timezone other than the JVM's timezone, you **must** use the zone-aware java data types.

---

_[View the full topic](https://forum.inductiveautomation.com/t/gateway-timezones-and-script-function-behavior/107050)._