Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Usually, you do not need a new “leap-free” chrony setting. Keep each synchronization domain on one consistent time policy, remove leap-specific directives that no longer serve your reference-clock design, and test applications that assume a leap-second label such as 23:59:60. The international change is not a single operating-system or chrony release date: CGPM Resolution 4 (2022) says the maximum allowed difference between UT1 and UTC will be increased in, or before, 2035, with an implementation plan due by then.
That policy points toward a continuous realization of UTC, but operating systems, time-zone databases, reference clocks and vendors may transition on different schedules. Treat 2035 as a planning horizon, not as a date on which every server must be reconfigured at once.
What the 2035 decision changes—and what it does not
CGPM Resolution 4 (2022) states that the maximum value of the difference (UT1-UTC) will be increased “in, or before, 2035.” In practical terms, international timekeeping is moving toward allowing UTC to remain continuous for longer instead of inserting leap seconds whenever Earth-rotation measurements require them. The resolution does not prescribe one Linux configuration, one chrony release, or one universal cutover weekend.
Until national laboratories, reference-clock operators, distributions and vendors publish compatible procedures, your immediate responsibility is operational consistency. A chrony client should obtain time from sources that represent the same timescale policy. A server that distributes ordinary UTC/NTP should not be silently placed in a group that also distributes a smear. A device that needs a correct TAI-UTC offset may still need leap-history data even if future insertions stop.
#1 Best Overall
- Stratum 1 NTP with GPS Source
- Embedded View-only Webserver with Status & Graphs
- Admin Console via USB and SSH
- Optional Dual Redundant Power Inputs - DC & PoE
- JSON Encoded Raw Data for Custom Integration
Three dates and terms to keep separate
- 2022: the General Conference on Weights and Measures adopted Resolution 4.
- 2035: the latest point named in the resolution for increasing the allowed UT1-UTC difference and having an implementation plan; it is not a guaranteed chrony cutover date.
- After implementation: individual software and data products may adopt new time-zone or reference-clock behavior at different times.
Choose one synchronization policy for each domain
Before changing a configuration, decide whether the host belongs to an ordinary UTC/NTP domain or to a deliberately smeared domain. The choice affects source compatibility, what time a server serves during a correction window, how legacy software sees a boundary, and how you trace the system to a reference time.
| Design | Sources that can be combined | Time served during a leap correction | Coordination requirement | Typical compatibility concern |
|---|---|---|---|---|
| Ordinary UTC/NTP | Sources that all provide the same unsmeared UTC/NTP policy | The source’s normal UTC/NTP representation; inserted leap events, if any remain in the source policy, are handled according to chrony and the operating system | Keep servers and clients on the same unsmeared policy and document the reference chain | Software that cannot parse leap indicators or the label 23:59:60 |
| Leap smear | Only servers using the identical smear profile and interval | Intentionally differs from UTC while the correction is spread over time | Every participating server and client must use the same smear design | Mixing smeared and unsmeared sources produces disagreement and can make source selection unstable |
There is no universal smear duration. Chrony’s documented example is one implementation, not a global standard. RFC 8633 warns that leap smearing must not be used for public-facing NTP servers because smeared servers disagree with non-smearing servers and with UTC during the smear interval. Keep a smear inside a controlled synchronization group whose participants have an explicit, identical policy.
Audit your existing chrony configuration
Start with an inventory rather than deleting directives based on their names. Read the main chrony.conf, distribution drop-in directories, package defaults and configuration-management templates. Record the installed chrony version and the source addresses or pool names in use.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Find the directives that need a policy decision
leapsectz right/UTCobtains leap announcements and TAI-UTC information from a leap-aware time-zone database. It is useful when a reference clock does not announce a leap, announces it too late, or when the system must maintain a correct TAI-UTC offset. It is not a requirement for an ordinary client merely because chrony is installed.leapsecmodetells chrony how to handle an announced leap. The documented modes aresystem,step,slewandignore. Select a mode because of the behavior you require, not because a sample file contains it.smoothtimechanges the time chrony serves to clients. It is a server-side smoothing policy, not a general client setting for a future without leap insertions.
Also search templates, container images and appliance configuration for hard-coded TAI-UTC values, leap-indicator handling and tests that expect an extra second. A clean chrony file does not protect an application that still assumes every day has exactly 86,400 labeled seconds.
Rank #2
- 1. GPS Satellite Time Synchronization: This NTP server receives global time signals from GPS satellites, ensuring nanosecond-level time synchronization accuracy, providing high reliability for your network equipment.
- 2. High-Precision NTP Service: Provides SNTP/NTP time synchronization with Daylight Saving Time (DST) support for finance, communications, and government.
- 3. Low Latency and High Performance: Optimized design with ultra-low network latency, ensuring multi-device sync accuracy to the millisecond level, ideal for applications where time precision is critical.
- 4.Flexible Dual-Power Deployment: Supports either AC power (wide voltage input 110V-264V) or standard PoE (IEEE 802.3af/at).
- 5. Easy-to-Use Web Management Interface: Supports easy installation and remote management. The intuitive interface makes it easy to monitor device status, configure settings, and maintain the system — ideal for IT administrators and technical teams.
Configuration for ordinary clients and unsmeared servers
For a normal workstation, VM, application host or unsmeared NTP server, point chronyd at reliable, mutually consistent sources and avoid unnecessary smear directives. The future policy does not require inventing a new directive. Keep a leap-related line only when the installed version and your reference-clock design require it.
Migration procedure
- Inventory. Capture the active configuration, drop-ins, package version and source list. Identify every
leapsectz,leapsecmodeandsmoothtimeline, including lines generated by automation. - Classify the host. Mark it as an ordinary client, an unsmeared NTP server, a leap-aware reference-clock server or a leap-smearing server. A host can be a client upstream and a server downstream, so classify both roles.
- Remove accidental smearing. Ordinary clients and unsmeared servers should not carry a
smoothtimepolicy copied from a different synchronization domain. Remove it through your configuration-management system, not only by editing a generated file. - Review
leapsectz. Retainleapsectz right/UTConly if the reference-clock arrangement or the installed chrony version still needs leap-history or TAI-UTC data. Otherwise remove it after checking distribution and vendor guidance. Do not remove it from a design that explicitly depends on that offset without replacing the dependency. - Review
leapsecmode. Keep a mode when you have a documented requirement for how an announced leap is handled. If the host is no longer expected to process announced insertions, do not leave a mode in place solely as cargo cult; validate the resulting behavior with the installed chrony documentation. - Reload using the supported service mechanism. Service names and reload commands vary by distribution and packaging. Use the command documented for the installed unit or init script, then confirm that chronyd accepted the file and remained running.
- Inspect synchronization. Use the
chronyccommands available in your installation to inspect source selection and tracking (commonlychronyc sources -vandchronyc tracking). Confirm that the selected source is the intended policy, that reachability is healthy and that the reported stratum and offsets are plausible for your network. - Check dependents. Review databases, message queues, appliances, monitoring jobs and data pipelines for assumptions about
23:59:60, leap-indicator bits or a hard-coded TAI-UTC offset.
What a successful change looks like
- The active file contains only directives justified by the host’s role.
- All upstream sources in the domain follow the same UTC/NTP or smear policy.
- Chrony selects a reachable source after reload and reports normal tracking.
- Automation will reproduce the change after a reboot or package update.
- Applications have an explicit policy for timestamps around a boundary instead of relying on an undocumented leap behavior.
When leapsectz right/UTC should stay
The name can be misleading: right/UTC is a leap-aware time-zone database view, not a switch that makes a client “more synchronized.” Chrony documents it for cases where the reference clock does not announce a leap second or announces it too late, and for systems that need the correct TAI-UTC relationship.
Keep it when all of the following are true:
- Your reference-clock design depends on a leap-aware database or on obtaining TAI-UTC information from it.
- The installed chrony and time-zone-data packages support the arrangement.
- You have tested how your applications consume the resulting clock and offset information.
Plan a controlled removal when those conditions no longer apply, especially after your distribution changes its time-zone data or your reference source adopts a continuous-UTC policy. Remove it from the managed configuration, reload chrony, inspect tracking and verify the TAI-UTC consumers separately. Chrony’s documentation specifically says clients of leap-smearing servers must not use this directive.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteHow to configure a chrony leap-smearing server
Use smearing only for a deliberately managed synchronization group. A client of a smeared server must obtain time from servers using the same smear profile; failover to an ordinary public pool source during the smear can introduce a real disagreement.
Rank #3
- Stratum 1 NTP with GPS Source
- Embedded View-only Webserver with Status & Graphs
- Admin Console via USB and SSH
- JSON Encoded Raw Data for Custom Integration
- I/O Connector
Chrony’s documented example
leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001024 leaponlyIn the chrony project’s current 4.7 documentation, this example starts the smear at 00:00:00 UTC and completes it after 62,500 seconds (about 17.36 hours). The maximum frequency offset reaches 32 ppm after 31,250 seconds. The example also specifies a maximum slew rate of 1,000 ppm and a smoothing rate of 0.001024 ppm per second. These numbers describe that documented chrony implementation; they are not a standard duration or profile for every NTP service.
Chrony cautions that a smearing server is intentionally not serving its best estimate of true time during the operation. That trade-off can protect applications that cannot tolerate a step or a leap label, but it reduces direct traceability to UTC for the smear interval. Document the profile, start condition, expected duration and monitoring behavior for every server in the group.
Smear deployment checklist
- Define the smear profile and the synchronization boundary in writing.
- Configure every authoritative server in that boundary identically.
- Ensure clients do not fail over to unsmeared sources during the smear window.
- Keep leap-aware database settings out of smear clients unless the design explicitly requires them; chrony says smear clients must not use
leapsectz. - Alert on a source that is outside the approved profile rather than automatically adding a public pool server.
- Test logs, certificates, schedulers, databases and telemetry across the entire smear interval.
NTP behavior after leap insertions change
NTP.org describes the NTP timescale as POSIX-based: inserted leap-second instances are ignored by that representation. Smearing applies the correction gradually instead. Those are different behaviors, not interchangeable labels for the same clock.
For an unsmeared domain, continue to select sources that represent ordinary UTC/NTP consistently. For a smeared domain, select only sources with the same smear policy. Do not mix public pool sources, cloud-provider smear sources and local unsmeared servers unless you have an explicit compatibility design, a clear source-preference strategy and tests for the disagreement interval.
Rank #4
- Up to 6000 visits per second
- Local area network synchronization timing accuracy: 0.5-2ms
- Support GPS, Beidou, GLONASS, QZSS NTP v2 (RFC 1119), NTP v3 (RFC 1305), NTP v4 (RFC5905)
- Internally integrated high- timing GNSS satellite receiver
- SNTP v3 (RFC 1769), SNTP v4 (RFC 2030)
Why mixing sources causes trouble
- During a smear, two otherwise healthy servers can report different times because one is intentionally offset from UTC.
- Chrony may see a source disagreement large enough to change selection or mark a source unusable.
- Applications that compare timestamps from different domains can record apparent negative or positive durations.
- Audit and forensic systems may lose a simple trace to UTC if the smear policy is undocumented.
Application and data checks
Changing chrony does not rewrite timestamps already stored or repair code that assumes a fixed civil-time model. Make a dependency inventory before your organization changes its reference policy.
Search for leap-specific assumptions
- Parsers that reject or normalize
23:59:60without an explicit policy. - Schedulers that assume every UTC day has exactly 86,400 seconds.
- Metrics code that interprets an NTP leap-indicator state as an error or ignores it unconditionally.
- Libraries or tables containing a hard-coded TAI-UTC offset.
- Distributed jobs that compare timestamps produced by smeared and unsmeared hosts.
- Retention, billing or billing-like calculations that convert civil timestamps to elapsed seconds without stating the timescale.
Make the policy visible in data contracts
For each timestamped interface, record whether values are UTC/NTP, POSIX-like, a named smear profile or another timescale. State how leap indicators, offsets and invalid labels are handled. Include the policy in runbooks and incident dashboards so an operator can distinguish a clock-source disagreement from an application defect.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshooting common migration failures
Sources disagree after reload
First compare policies, not just network reachability. Check whether one source is smeared, whether a stale configuration file still enables smoothtime, and whether an automated failover added a source from a different domain. Remove the incompatible source or place all servers under one documented profile, then inspect chrony’s source and tracking output again.
Recommended Free Tools
The host loses a TAI-UTC relationship
Review whether leapsectz right/UTC was removed from a host whose reference-clock design still needs it. Restore the directive through managed configuration if required, verify the installed time-zone data and chrony version, and test the consumer that uses the offset. Do not assume that ordinary UTC synchronization alone supplies the same TAI information.
Best Value
- 【Supports Three Satellite Signals】– Simultaneously receives GPS, GLONASS, and BEIDOU satellite signals, providing reliable and accurate network time for all connected devices.
- 【Dual Ethernet Ports for Seamless Integration】 – Equipped with 2 Ethernet ports for smooth network integration, suitable for both small and large-scale networks.
- 【PPS + TOD Support for High-Precision Time Distribution】 – Features Pulse Per Second (PPS) and Time of Day (TOD) connectors for advanced time synchronization, meeting the needs of time-sensitive applications.
- 【Optional Dual Redundnant Power Inputs】 –Support AC & POE Power
- 【Supports Multiple Protocols】 – Compatible with various NTP network time protocols (NTP v2, v3, v4, SNTP v3, v4), ensuring your system stays synchronized across diverse platforms and networks.
A leap-aware application fails even though chrony is healthy
Separate synchronization from parsing. Check logs and timestamp libraries for rejection of 23:59:60, fixed-length-day arithmetic or assumptions about leap-indicator bits. Give the application an explicit timescale policy and test boundary behavior in a controlled environment; changing the NTP source cannot correct a parser that has no defined leap behavior.
A smear client suddenly steps or changes offset
Look for an unsmeared fallback source, a server with a different smear duration, or a restarted server that lost its smoothing state. Confirm that every source in the client’s selection set uses the identical profile and that monitoring does not automatically add a public source during an alert.
Planning beyond 2035
Use the policy horizon to create checkpoints rather than a single cutover task. Track announcements from your distribution, chrony package maintainers, reference-clock provider and time-zone-data maintainers. At each change, revalidate source compatibility, leap directives, TAI-UTC consumers and application timestamp contracts.
- Now: inventory configurations, classify synchronization domains and remove accidental smear settings.
- Before a vendor or distribution transition: read its chrony and time-zone-data guidance, stage the change and test dependent systems.
- At implementation: change one controlled domain at a time, monitor source selection and compare timestamps across domains.
- Afterward: retain an audit record of the chosen timescale, source chain, directives and application behavior.
The durable rule is simple: ordinary clients need a source-policy review, not a speculative “no leap seconds” directive. Smearing is a coordinated exception, not a default. Keep leapsectz, leapsecmode and smoothtime only when their distinct purposes match the design you operate.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
