Fixing Incorrect Date and Time on FreeDOS

FreeDOS reads its initial date and time from the system’s Real-Time Clock (RTC) hardware at boot — a value that’s wrong every single session, rather than just occasionally, points at a different cause than one that drifts gradually over time.

Step 1: check the date/time immediately after boot

DATE
TIME

Step 2: distinguish “wrong every boot, same wrong value” from “correct at boot, drifts afterward”

A date/time that’s wrong by the same amount every single boot, and doesn’t change between sessions even with the system powered off for a while, points at the CMOS/RTC hardware itself; a date/time that drifts progressively over uptime (correct at boot, wrong hours later) is a completely different, software-timekeeping issue.

Step 3: for a consistently wrong date resetting to a fixed value, suspect the CMOS battery

On real hardware, a dead or dying CMOS battery is the classic cause of the clock resetting to a fixed default date every time the system is powered off — check the motherboard’s CR2032 (or similar) battery and replace it if it’s old, particularly on genuinely vintage hardware that may have had the original battery for decades.

Step 4: for a virtual machine, check the VM’s own RTC/clock passthrough settings

Under emulation (DOSBox, a VM), the “hardware clock” FreeDOS reads is whatever the hypervisor presents — check the VM software’s own date/time and clock-passthrough configuration rather than assuming a hardware problem, since there’s no physical CMOS battery involved at all in this scenario.

Step 5: set the date/time manually and check whether it persists across a warm reboot

DATE 07-09-2026
TIME 14:30

Reboot without powering fully off (Ctrl+Alt+Del) — if the set values survive a warm reboot but are lost after a full power cycle, this specifically confirms CMOS battery failure as the cause, since the RTC chip itself is losing power entirely between sessions.

Step 6: check for a timezone-related misunderstanding, not an actual clock fault

FreeDOS’s DATE/TIME commands work with the RTC’s raw value directly — there’s no timezone abstraction layer the way modern operating systems have. A “wrong” time that’s actually correct but offset by your timezone difference from UTC (if the RTC is set to UTC rather than local time) isn’t a fault at all, just a different convention than expected.

Step 7: use a NIC and network time source, if networking is configured

See "how to set up networking on FreeDOS with mTCP" for
the networking prerequisite, then check for an SNTP
client utility in the FreeDOS package repository.

For systems with networking already configured, a periodic network time sync avoids relying on RTC accuracy at all for anything beyond the boot-time initial value.

Why the “persists across warm reboot vs. not” test is the single most useful diagnostic step

This one test cleanly separates a genuine RTC hardware fault (battery dead, chip failing) from every other possible cause, since only actual loss of power to the RTC circuit between sessions explains time surviving a warm reboot but not a cold one. Running this test before assuming either “the battery must be dead” or “it’s a software problem” avoids wasted effort chasing the wrong category of fix.