Because it used to be necessary.
While a battery-powered real-time clock is standard today, this wasn’t always the case. The very first IBM 5150 did not include an RTC chip; the system clock was maintained by the PIT interrupt running on the CPU, which in particular meant that disabling interrupts halted the system clock. When the computer was turned off, there was no hardware inside to maintain the clock. A number of third-party extension boards were available to overcome this problem; only with the PC/AT did an RTC chip become a built-in feature.
The above part is uncontroversial. The rest of this answer is considerably more speculative.
Skipping the date and time prompt when AUTOEXEC.BAT
is present allowed the user to establish the current date and time at boot-up in some other way than prompting for manual input (which was probably exploited by drivers for the above-mentioned devices). In fact, this seems to have been the original purpose of AUTOEXEC.BAT
in the first place: the /D
switch used to skip processing AUTOEXEC.BAT
was added primarily to suppress the date and time prompt, as implied by a comment in source code and overtly stated in internal documentation.
While an RTC eventually became a standard PC feature, Microsoft (and apparently Digital Research which developed DR DOS) probably wanted to maintain support for hardware which lacked it (including non-PC-compatible hardware), so instead of requiring the user to input the date and time, DOS started to allow the user to confirm the current setting. By the time computers without an RTC became vanishingly rare, this behaviour became a non-issue, as most computers would have an AUTOEXEC.BAT
file present anyway, if only to set the PATH
environment variable. DOS vendors therefore focused their attention on other concerns.
Also, even a battery-powered RTC would occasionally need to be manually adjusted for Daylight Saving Time and to correct clock skew (thanks @Ron Maupin for pointing the latter out), as the RTC on DOS computers was, infamously, usually set to local time and tended to drift a lot (as it does to this day, but now at least we have NTP to take care of it). Prompting the user to confirm the current time could serve as a mechanism ensuring the clock is set more-or-less accurately and that the DST adjustment is not overlooked. (This seems a weak justification now, especially given it’s a speculative one, and seems to contradict the AUTOEXEC.BAT
connection somewhat. Myself, I would expect this behaviour to instead train the user to press Enter twice each time the system boots up without paying attention to the prompt. But maybe it is only in hindsight that we understand effects like banner blindness.)
With Windows 95, booting without an AUTOEXEC.BAT
file became a much more common (and in fact, preferred) configuration: Andrew Schulman’s Unauthorized Windows 95 makes note that this was much emphasised in the press at the time. In a clean installation, only the non-English versions would create an AUTOEXEC.BAT
file, where it would invoke MODE
and KEYB
commands setting up DOS locale settings. Only then did Microsoft decide that asking for the date and time on boot-up is superfluous and removed it, whether AUTOEXEC.BAT
was present or not. (Even the DST justification wouldn’t have made sense any more, as DST adjustments are instead handled by the graphical interface.) Other DOS vendors apparently never felt the need to address it.
command.com
did this automatically? I seem to remember Compaq DOS 3.1 requiring explicitdate
andtime
commands to be placed inautoexec.bat
to get this prompt on startup.AUTOEXEC.BAT
file will suppress the prompt. Then though, there is also a possibility that Compaq DOS contained a modified version ofCOMMAND.COM
.date
command and in the section onautoexec.bat
. Google Books tells us that it's also in the 1984 COMPAQ User's Handbook.autoexec.bat
part of the statement that I missed. Not sure I ever booted without a startup script, so never saw the automatic display.