Downtime and report times are 3 hours off after moving the server to a new PC

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • SignalFlow
    Junior Member
    • 21.10.2026
    • 7

    #1

    Downtime and report times are 3 hours off after moving the server to a new PC

    We moved Proveris OEE to a new server PC over the weekend (new Windows install, new PostgreSQL install, database restored from backup). Everything is running, but the times look wrong. A downtime that happened at 10:15 shows as 07:15, and the shift report for 06:00–14:00 seems to include data from the previous night.
    Windows clock on the server shows the correct local time. I'm not sure if this is a browser, Windows or database problem. Where should I start looking?
  • Technical Support
    Senior Member
    • 11.08.2025
    • 105

    #2
    A fixed offset of a few hours after a server move almost always means the operating system and PostgreSQL are using different time zones. A fresh PostgreSQL installation often defaults to UTC, while Windows is set to local time.
    1. Check with the built-in tool
    Go to HELP > TIMEZONE CHECK. The page "Checks OS and PostgreSQL timezone configuration." and shows a Timezone Status card with a Match Status. If they don't match, that's your problem.
    2. Fix the PostgreSQL time zone
    Set the timezone parameter in PostgreSQL's configuration (postgresql.conf) to the same zone as Windows, for example Europe/Istanbul, then restart the PostgreSQL service. If you're not comfortable editing the file, your database administrator can do it in a few minutes.
    3. Restart the Proveris server
    After PostgreSQL is restarted, restart the Proveris server from the Server Status page with Restart, so it reconnects with the new setting. Run the timezone check again and confirm it matches.
    4. Records from the weekend
    Records written while the zones were mismatched may need correction. Before changing anything, take a backup, note the exact time window, and contact us through support. We'd prefer to look at it with you rather than have you run bulk updates on the database.
    5. Shift boundaries
    Once the zones match, open Shift Monitoring and step through a few shifts with "Previous shift" to confirm the 06:00–14:00 shift starts and ends where you expect.
    It's a good idea to add the timezone check to your server migration checklist.
    Documentation: https://greensoft.ai/documentation/p...ine-interface/

    Comment

    Working...