How to change day and night length on a DayZ PC server
Change serverTimeAcceleration to control the DayZ server clock, then use serverNightTimeAcceleration to adjust night speed. The two values multiply during the night. Save the active configuration, restart and check the clock inside the game.
This procedure covers DayZ Standalone PC, including a self-managed dedicated server and managed PC hosting. You need a working server you can join before changing its time settings.
Find the configuration your server loads
Section titled “Find the configuration your server loads”On a self-managed server, read the -config startup argument to identify the active file. Editing another copy of serverDZ.cfg will leave the running configuration unchanged.
Save a copy of that file and record the current time fields. Stop the server through its supported shutdown control before editing. The examples below are partial changes for an existing configuration; keep your mission, ports and access settings.
For VYKIX hosting, open Configuration → Config, refresh the saved configuration and use the grouped Time fields. Save, then restart through Console. Native .cfg syntax does not belong in the panel’s raw JSON editor.
Understand the four time settings
Section titled “Understand the four time settings”Bohemia’s server configuration reference documents these fields:
| Setting | What it controls |
|---|---|
serverTime |
Initial game date and time. Accepts "SystemTime" or a date in "YYYY/MM/DD/HH/MM" format. System time means the server machine’s local clock. |
serverTimeAcceleration |
Base clock multiplier, from 0.1 to 64. A value of 6 advances six game minutes per real minute outside the night multiplier. |
serverNightTimeAcceleration |
Night multiplier, from 0.1 to 64. It multiplies the base value during night. |
serverTimePersistent |
With 1, the server saves the game time and uses it at the next start. With 0, startup uses the initial-time setting. |
Use this relationship when choosing values:
Effective night speed = serverTimeAcceleration × serverNightTimeAccelerationFor example, base acceleration 6 and night acceleration 2 produce a night speed of 12. Setting night acceleration to 1 keeps the base speed through the night.
Choose a starting configuration
Section titled “Choose a starting configuration”For a first test with faster nights, edit the existing entries to:
serverTime = "2026/9/20/12/00";serverTimeAcceleration = 6;serverNightTimeAcceleration = 2;serverTimePersistent = 0;This example starts at noon on the selected game date, runs the base clock at six times normal speed and multiplies night speed by two. Disabling persistent time makes the restart check repeatable. Choose persistence after the test according to whether you want the clock to resume or return to the configured starting time.
Check the mission’s date logic too. The stock Chernarus init.c resets dates outside its seasonal window to 20 September after economy initialization, retaining the hour and minute. The example uses that date. Other missions and mods can apply different rules, including after loading saved time; inspect the game date before estimating daylight length.
Do not add a second set of time fields beneath the existing ones. Replace their values, save and restart. Check startup logs for configuration errors before joining.
Estimate length without assuming every night is 12 hours
Section titled “Estimate length without assuming every night is 12 hours”Let D be the daylight hours and H the night hours in the game cycle you are evaluating. With base multiplier A and night multiplier N:
Real daylight hours ≈ D / AReal night hours ≈ H / (A × N)Real cycle hours ≈ D / A + H / (A × N)These calculations follow the documented multiplier relationship. They estimate a cycle with fixed day and night intervals; your observed transition times determine D and H.
The examples below assume 12 game hours of daylight and 12 of night. They show the arithmetic, not measured durations for a particular map or date.
Base A |
Night N |
Effective night speed | Daylight under that assumption | Night under that assumption |
|---|---|---|---|---|
| 6 | 1 | 6× | 2 real hours | 2 real hours |
| 6 | 2 | 12× | 2 real hours | 1 real hour |
| 6 | 4 | 24× | 2 real hours | 30 real minutes |
| 2 | 4 | 8× | 6 real hours | 90 real minutes |
Measure your intended map and game date before promising players a fixed night length. Define whether your measurement includes dusk and dawn, then use that definition for later comparisons.
If you want a particular duration, calculate A = D / desired daylight hours, then N = H / (A × desired night hours). Keep each configured multiplier within its documented range and test the result.
Check the clock inside the game
Section titled “Check the clock inside the game”A June 2026 Reddit report describes the launcher displaying 64× despite a different LAN server setting. That is one user’s report; it does not establish a fault on your server.
Use a watch or your existing admin tool to read game time. During a daylight interval:
- Note the game time and real time.
- Remain connected for ten real minutes, without crossing dusk.
- Read the game clock again. At base acceleration
6, the expected advance is about one game hour. - Repeat during night. With base
6and night2, ten real minutes should advance about two game hours.
Allow for reading precision. For a test crossing midnight, include the date change when calculating the elapsed game time. If the measured rate differs, check the active file and installed time-control mods before increasing the multipliers.
Decide what should happen after a restart
Section titled “Decide what should happen after a restart”Use serverTimePersistent = 1; when the game clock should continue from its saved time. The configured initial time may not appear after a restart because the server restores that saved value.
For a repeatable initial time, use serverTimePersistent = 0; and an explicit serverTime date. Restart once and verify the game clock. Changing the time policy does not require deleting world persistence or player data.
A daytime start also does not guarantee a daytime session. The clock advances until dusk unless another configured mechanism intervenes. If you choose scheduled restarts to return to a daytime start, check that persistence is off and measure whether dusk arrives before the restart. Announce that policy to players and verify the schedule’s timezone.
Treat night brightness as a separate change
Section titled “Treat night brightness as a separate change”Shorter nights still have a dark period. If you want to change visibility, review the lighting and personal-light settings after validating time. An enabled cfggameplay.json can override the configuration’s lighting preset; check the active controls before editing both files.
Record brightness and time as separate tests so a lighting change does not obscure a clock problem.
Fix a result that does not match your settings
Section titled “Fix a result that does not match your settings”| Result | Check |
|---|---|
| Editing has no effect | Confirm -config, duplicate keys, saved values and a completed restart. |
| Night runs faster than expected | Multiply the base and night values; the night field is an additional multiplier. |
| Start time is ignored after restart | Check persistent time, the system-time option and mission date-reset logic. |
| The launcher shows another rate | Compare the in-game clock over a measured interval. |
| Time changes despite matching configuration | Inspect time-control mods and mission scripts for an override. |
| Night is shorter but visibility is unchanged | Review brightness controls as a separate setting. |
To roll back, stop the server, restore the saved time fields and restart. Repeat the clock and restart checks before returning the server to normal use.
Completion check: the measured daylight and night rates match your intended values, and the clock resumes or resets after a restart according to your chosen policy.