Server Mode → Settings → Server Time lets you view and manage the server's clock, timezone, and NTP synchronisation status — all without an SSH session.
What the Page Shows
- Current time — the server's current local time, read from the Agent's
/system/timeendpoint. - Timezone — the active IANA timezone (e.g.,
America/New_York,Europe/London,UTC). - NTP sync status — whether the system clock is currently synchronised to a time server.
- Last sync — timestamp of the most recent successful NTP sync.
Changing the Timezone
Use the Timezone dropdown to select any IANA timezone. Click Apply. The Agent executes:
timedatectl set-timezone America/New_York
The change takes effect immediately on the server. The Panel reflects the new time on the next page load.
Note: Changing the timezone does not restart any services. However, services that cache the timezone at startup (some PHP applications, cron jobs) may need a reload to reflect the change. PHP-FPM picks up timezone changes via
date.timezoneinphp.ini— changing the OS timezone does not automatically affect PHP unlessdate.timezoneis set to an empty string or the FPM pool is restarted.
Forcing an NTP Sync
Click Sync Now. The Agent runs:
chronyc makestep
Or, if chrony is not available:
ntpdate -u pool.ntp.org
A success or failure message is returned to the Panel immediately. If sync fails, check that the server has outbound UDP access to port 123.
Why Server Time Matters
Getting server time wrong causes cascading failures that can be difficult to diagnose:
HMAC signature verification — the Opterius Agent validates request timestamps to prevent replay attacks. If the server clock drifts more than 5 minutes from the Panel clock, API calls will be rejected with a signature error. If you see 401 Timestamp mismatch errors in the agent log, check the server time first.
TLS certificate validation — TLS clients verify that the current time falls within a certificate's validity window. A server with a wrong clock can fail to validate its own certificates or certificates presented by upstream services.
Cron schedules — cron evaluates schedules against the system clock. A drifted clock causes jobs to fire at wrong times or not at all.
Log timestamps — inconsistent timestamps across servers make correlating logs across machines difficult. Keeping all servers in UTC simplifies log analysis.
Tip: Run all servers in UTC. Set your local timezone in the Panel UI or in your own workstation — not on the server itself. This avoids timezone-related surprises during daylight saving time transitions.
Checking Time via SSH
timedatectl status
chronyc tracking