When dealing with significant time offsets (in this case, 6 years) between a Chrony NTP server and its clients, the default Chrony configuration may fail to synchronize properly. The system logs typically show messages like:

Jan  9 17:29:11 localhost chronyd[9192]: System clock wrong by 6780812.328260 seconds, adjustment started

Chrony is designed to handle time synchronization carefully to avoid abrupt changes that could disrupt system operations. By default:

• For small offsets (<1000s), it uses clock slewing (gradual adjustment)
• For larger offsets, it may step the clock (instant adjustment)
• Extreme offsets (years) require special configuration

To force synchronization with such large time differences, we need to modify both server and client configurations:

Server Configuration (/etc/chrony.conf)

# Basic server configuration
server 127.127.1.0
local stratum 10

# Important for large time jumps
allow all
cmdallow all

Client Configuration (/etc/chrony.conf)

server your.local.server iburst
makestep 1000 -1  # Allow unlimited stepping above 1000s
maxchange 1000000000  # Remove default limit
stratumweight 0
driftfile /var/lib/chrony/drift
rtcsync

Here's the complete workflow to resolve the issue:

1. On the server:

   systemctl stop chronyd
   date -s "2017-01-01 00:00:00"  # Example 6 years back
   systemctl start chronyd

2. On the client:

   systemctl stop chronyd
   chronyd -q 'server your.local.server iburst'  # Force immediate sync
   systemctl start chronyd

After making these changes, verify synchronization with:

# Check tracking status
chronyc tracking

# View sources
chronyc sources -v

# Check server connectivity
chronyc serverstats

If you still face issues, consider:

• Using chronyc makestep command to manually step the time
• Temporarily setting local stratum 10 on client when isolated
• Checking firewall rules that might block NTP traffic (UDP port 123)

Remember that large time jumps can affect:

• Application logs and timestamps
• SSL/TLS certificate validation
• Cron jobs and scheduled tasks
• Database transactions with temporal data

For production systems, it's recommended to:

1. Schedule maintenance windows for time changes
2. Test time adjustments in staging environments first
3. Monitor affected applications after synchronization

When dealing with extreme time differences (like the 6-year offset in this case), Chrony's default behavior prioritizes system stability over immediate correction. The key factors at play:

# Relevant chrony.conf directives affecting large time jumps:
makestep 10 3     # Only allows stepping up to 10 seconds initially
maxslewrate 1000  # Default maximum slew rate (ppm)
maxchange 1000 0  # Default maximum correction (seconds) before panic

Chrony is deliberately designed to handle large time discrepancies carefully:

• The 6780812-second difference exceeds Chrony's default safety thresholds
• Automatic slewing at maximum rate would take ~78 days to correct
• The makestep directive only handles smaller initial offsets

For testing environments where immediate sync is needed:

# Option 1: Force immediate time jump (requires chronyd restart)
sudo chronyc -a 'burst 4/4'
sudo chronyc -a 'makestep 0.1 3'

# Option 2: Modify configuration for large offsets
# /etc/chrony.conf additions:
maxslewrate 1000000    # Allow faster slew rate
maxchange 10000000 0   # Allow larger corrections
makestep 1000000 1     # Immediate step for huge differences

For production systems, consider these safer approaches:

# Safer incremental approach:
1. First correct to within 1000 seconds:
   sudo date -s "@$(($(date +%s) - 1000))"
2. Then let chrony handle the remaining offset
3. Gradually increase maxslewrate if needed

Use these to monitor sync progress:

chronyc tracking    # Show current offset
chronyc sources -v  # Verify server connectivity
journalctl -u chronyd -f  # Monitor real-time logs