Share via

Windows Time Changes Randomly to Previous date

Anonymous
2025-02-10T22:40:53+00:00

Hello,

I have a 3 node Windows 2019 server cluster. The cluster is running a Postgresql server and i have noticed in the database that for a period of 10-20 minutes the timestamps will be a time way in the past. For example, the most recent is March 5th, 1906. i have confirmed that in the Time Service event log the time change does appear there. the domain controller is set to use NTP time and the cluster nodes get their time from the DC. I can see the time change occurs on the DC as well as other nodes.

I have checked the ntp source and time does not change on that server. Then cluster nodes have been up for almost 3 years. Not sure if this is contributing to the issues. Here is some information from the event logs.

Log Name: Microsoft-Windows-Time-Service/Operational Source:

Microsoft-Windows-Time-Service Date: 3/5/1906 5:56:38 PM

Event ID: 261 Task

Category: None

Level: Information

Keywords:

User: LOCAL SERVICE

Computer: ClusterNodeC.company.Local

Description: W32time service has set the system time to 1906-03-06T01:56:38.759Z(UTC). Previous system time was 2025-02-09T08:44:43.226Z(UTC). System Tick Count: 86281034171 For more information, see https://go.microsoft.com/fwlink/?linkid=845961. Event

Xml: 261 0 4 0 0 0x4000000000000000 590013

Microsoft-Windows-Time-Service/Operational ClusterNodeC.company.Local 1906-03-06T01:56:38.759Z 2025-02-09T08:44:43.226Z 86281034171

Log Name: Microsoft-Windows-Time-Service/Operational

Source: Microsoft-Windows-Time-Service

Date: 3/5/1906 5:59:02 PM

Event ID: 259 Task

Category: None

Level: Information Keywords:

User: LOCAL SERVICE

Computer: ClusterNodeC.company.Local

Description: NTP Client provider periodic

status: Ntp Client is receiving time data from the following NTP Servers: 10.255.2.1,0x1 (ntp.m|0x1|0.0.0.0:123->10.255.2.1:123); and the chosen reference time server is . System Tick Count 86281178203. IFTSTMP:0. For more information, see https://go.microsoft.com/fwlink/?linkid=845961. Event Xml: 259 0 4 0 0 0x4000000000000000 590016 Microsoft-Windows-Time-Service/Operational ClusterNodeC.company.Local 10.255.2.1,0x1 (ntp.m|0x1|0.0.0.0:123->10.255.2.1:123); 86281178203 0

Any insight as to what the issue might be would be most helpful.

Thank you,

Scott

Windows Server Identity and access Active Directory

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question. To protect privacy, user profiles for migrated questions are anonymized.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2025-02-11T07:41:34+00:00

    Hello

    It looks like you're dealing with a time sync issue where the system clock on your Windows Server 2019 cluster nodes (and possibly the Domain Controller) is resetting to an incorrect date and time (e.g., March 5, 1906) for short periods. This issue can cause data integrity problems, especially with database systems like PostgreSQL.

    Based on the event logs you provided and the context, here are a few potential causes and troubleshooting steps to help resolve this issue:

    1. Time Synchronization and NTP Configuration

    The most likely issue seems to be with the NTP synchronization. You mentioned that the Domain Controller is set to use NTP time, but the cluster nodes are receiving incorrect time. It's important to confirm that both the Domain Controller and the cluster nodes are using a reliable and stable time source. Here are some things to check:

    Check Time Configuration on the Domain Controller:

    Ensure the Domain Controller is properly synchronized with a reliable external NTP server.

    Run w32tm /query /status on the DC to verify the current time source.

    Ensure the DC is syncing with a valid NTP server and not with a local machine or a misconfigured source.

    Use a public NTP server or a hardware time source if possible (e.g., time.windows.com or pool.ntp.org).

    Check NTP on the Cluster Nodes:

    Ensure that the cluster nodes are correctly configured to sync with the Domain Controller as their NTP source.

    Run w32tm /query /source on the cluster nodes to verify that the NTP source is set to the Domain Controller.

    You can also force the NTP sync by running w32tm /resync on the cluster nodes and checking if the time corrects itself.
    If the nodes are not syncing correctly, you can try to reconfigure the NTP settings on the nodes:
    w32tm /config /manualpeerlist:"<DC_IP_or_NTP_Server>" /syncfromflags:manual /reliable:YES /update

    1. W32Time Service

    The W32Time service (Windows Time service) might be having issues, especially in a cluster environment where time synchronization is critical. The Event ID 261 indicates that the system is being forced to reset the time.

    Reset the Windows Time Service:

    Try restarting the Windows Time service on both the Domain Controller and the cluster nodes:
    net stop w32time
    net start w32time

    You can also configure the service to be more reliable by setting it as "reliable":
    w32tm /config /manualpeerlist:"<your NTP server>" /syncfromflags:manual /reliable:YES /update

    After resetting, monitor the event logs to see if the issue continues.

    1. Clock Drift / Hardware Issues

    Since you mentioned that the nodes have been up for almost 3 years, it's possible that hardware-related issues (e.g., clock drift) might be contributing to the problem. You should check for:

    System clock issues: Ensure that the system's hardware clock (CMOS) is functioning correctly. Sometimes, a failing CMOS battery can cause time resets.
    To check the hardware clock:
    w32tm /stripchart /computer:<your_server_IP> /samples:5

    1. PostgreSQL and Time Handling

    It's important to ensure that your PostgreSQL server isn't handling time incorrectly due to these changes in the system time. If the system clock is jumping, PostgreSQL might store timestamps in an unexpected manner, which could explain the weird values (like "March 5th, 1906").

    Check PostgreSQL configuration: Ensure that PostgreSQL is using UTC for time handling to avoid confusion with time zones.

    Verify that timestamps are stored correctly in the database and ensure no "time zone drift" is happening due to time inconsistencies.

    1. Event ID 259 and 261 Analysis

    The logs you’ve shared show that Event ID 259 is being logged, which is a periodic NTP sync log entry. The system is confirming it’s receiving time data from NTP servers (in your case, 10.255.2.1), but then Event ID 261 shows a drastic time change to a previous date (1906-03-06T01:56:38.759Z), which could suggest some sort of synchronization issue or a service trying to revert to an incorrect time source.

    Check for time service misconfiguration: If there’s a time source conflict or misconfiguration in the NTP client setup, the system may attempt to adjust the time based on incorrect or outdated information.

    1. Cluster Nodes & Long Uptime

    Since the cluster nodes have been up for almost 3 years, you might be facing some cumulative issues related to uptime, including:

    Software bugs that could cause time synchronization issues in long-running clusters.

    Memory issues or kernel bugs related to long-running services.

    I hope the above information is helpful to you.

    Best regards

    Runjie Zhai

    0 comments
  2. Anonymous
    2025-02-13T19:28:15+00:00

    Thank you Runjie.

    I will follow your instructions and see if that resolves the issue.

    Have a good day,

    Scott

    0 comments