# Ignition Clock Drift Events

**URL:** <https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435>\
**Category:** Ignition\
**Created:** [December 4, 2024, 5:40pm UTC](https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435 "2024-12-04T17:40:57Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Shong\_Liew](https://avatars.discourse-cdn.com/v4/letter/s/848f3c/32.png) [@Shong\_Liew](https://forum.inductiveautomation.com/u/Shong_Liew)\
**Post date:** [December 4, 2024, 5:40pm UTC](https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435/1 "2024-12-04T17:40:57Z")

</div>

I am experiencing weird clock drift and cannot tell if it is my server causing this issue. My expectation is ignition gets its clock from server/pc where it is running.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/8/389882b2c82abb9cc3f6216133e425f72584a8ef.png)

The problem is, we haven't event get to 19Apr2025 yet, and now I get that events and I am trying to find a way to detect if my server/pc change system time randomly.

This is currently creating problematic events where my historian starts to log that future time into my database so is there a way to resolve this clock drift events?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [December 4, 2024, 5:44pm UTC](https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435/2 "2024-12-04T17:44:11Z")

</div>

That's a big jump... almost 140 days?

Maybe set up an NTP Server or otherwise make sure your server's clock is regularly being synced...

---

<div class="post-metadata">

**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\
**Post date:** [December 4, 2024, 8:09pm UTC](https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435/3 "2024-12-04T20:09:06Z")

</div>

If you're working on a system that can't be connected to a normal time server you can buy an atomic clock and synch with that. We had to do that for a prison job once.

> **[Atomic Clocks](https://www.microchip.com/en-us/products/clock-and-timing/components/atomic-clocks)**
>
> Check out our broad portfolio of laboratory-grade system atomic clocks and small PCB-mountable atomic oscillators based on atomic resonance techniques.

---

<div class="post-metadata">

**Author:** ![Shong\_Liew1](https://avatars.discourse-cdn.com/v4/letter/s/b77776/32.png) [@Shong\_Liew1](https://forum.inductiveautomation.com/u/Shong_Liew1)\
**Post date:** [December 4, 2024, 8:18pm UTC](https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435/4 "2024-12-04T20:18:02Z")

</div>

Does that mean when ignition gets wrong time, everything is messed up? Is there any fault tolerant settings that can be setup to handle clock drift that much?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [December 4, 2024, 8:19pm UTC](https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435/5 "2024-12-04T20:19:37Z")

</div>

Ignition gets its time from the OS. It needs to be addressed by ensuring the system clock is relatively accurate.

---

<div class="post-metadata">

**Author:** ![eric.peery](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/eric.peery/32/11897_2.png) [@eric.peery](https://forum.inductiveautomation.com/u/eric.peery)\
**Post date:** [March 10, 2025, 5:49pm UTC](https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435/6 "2025-03-10T17:49:17Z")

</div>

We had the same thing happen to one of our development servers. Ignition version 8.1.44, virtual environment, server is getting it's time signal from the same domain controller that the rest of the network uses. From these entries you can see that it jumped 2 days forward, then another 5 days forward.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/1/9122bfbe3db1b29b74771e094eaf4de6f93d60d2.jpeg)

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/b/3b9ec2bf0339f318304b31d0dbaaf88b52988f7f.png)

A few minutes later the server re-synced back to the correct time.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [March 10, 2025, 5:54pm UTC](https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435/7 "2025-03-10T17:54:50Z")

</div>

You can treat these as informational if they are not causing you any issues.

Otherwise you have to deal with this somehow. Perhaps a more reliable NTP source than whatever Windows has built in, which happily "warps" backwards and forwards through time instead of using a slow skew for corrections.

---

<div class="post-metadata">

**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\
**Post date:** [March 10, 2025, 6:06pm UTC](https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435/8 "2025-03-10T18:06:26Z")

</div>

Not sure what type of hardware you're using, but we've had issues with Windows' built in NTP client on certain types of hardware such as the SEL-3355 computer.

A great workaround is to use a third party NTP client such as this free Meinberg one: [Meinberg NTP Software Downloads](https://www.meinbergglobal.com/english/sw/ntp.htm)  
It also gives you much more flexibility for multiple NTP sources, failover, etc.

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [March 10, 2025, 8:14pm UTC](https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435/9 "2025-03-10T20:14:19Z")

</div>

Here's a link to some cheap GPS NTP servers, or upgrade to a better one that also supports PTP.

> **[GPS NTP Time Server Device (TM1000A) | TimeMachines Inc.](https://timemachinescorp.com/product/gps-time-server-tm1000a/)**
>
> Need all your computers to have synchronized time? Our NTP server device is what you need. Our GPS NTP time server TM1000A is top-rated.

Here's the NTP and PTP model:

> **[GPS NTP+PTP Network Time Server TM2000B](https://timemachinescorp.com/product/gps-ntpptp-network-time-server-tm2000/)**
>
> Use our strongest NTP+PTP Network Time Server with our TM2000B time server. With improved holdover accuracy with the same reliability as our other products.

And supposedly Windows does work with PTP also:

> **[Windows10PTPClient.pdf](https://timemachinescorp.com/wp-content/uploads/Windows10PTPClient.pdf)**
>
> 141.55 KB

---

<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:** [March 10, 2025, 8:20pm UTC](https://forum.inductiveautomation.com/t/ignition-clock-drift-events/99435/10 "2025-03-10T20:20:32Z")

</div>

> [@michael.flagler](#):
>
> also supports PTP

If you have modern Logix PLCs, putting a PTP source on your network is a huge win.
