The DOS Think way of keeping time is how time and timezones are managed in MS/PC/DR-DOS: The hardware real-time clock runs in local time, with daylight savings time adjustments, for one system-wide timezone, applied on the fly by the operating system (or manually twice a year by the system administrator). It is fundamentally and irredemably flawed. Nonetheless, people still use it even now. It's still the thinking as employed by Windows NT, for example.
It is, however (which surprises some people), not the way that 32-bit OS/2 was actually designed to keep time. Nor is it, of course, how Unix and Linux (when the latter is properly configured, at any rate) keep time.
The basic problems are twofold.
The first basic problem is a simple one: There's no flag in an MC146818 real-time clock chip (and thus in its emulators in modern chipsets) that says "This clock has had daylight savings time corrections applied.". (An equivalent flag would be "Daylight savings time is/is not currently in effect.")
The reason why this is a basic problem is that in order to have a DOS Think timekeeping system work reliably (where this is defined as being at least as reliably as the Unix-Linux-OS/2 way of keeping time is) with respect to daylight savings changes, a persistent flag is required, in a place that every DOS Think operating system agrees upon, that is updated at DST changover points even when the operating system is not running.
If there is no flag, or if different operating systems disagree as to where the flag is so that they each use different flags, or if the flag doesn't change when a DST transition occurs when no DOS Think operating system is running, the system becomes a mess.
Examples of how the system becomes a mess abound. They've been reported many times, by many people, since the 1980s. They are a perennial staple of the RISKS Forum.
What happens when there is no flag at all is exemplified by the behaviour of DOS-Windows 95, as reported by Dale K. Brearcliffe in 1997 and again by R.A. Downes in 1999. If there's no flag saved anywhere to say what the current DST state of the RTC is, when it comes to adjusting from daylight savings time to standard time, automatic adjustment enters the world of 12:01, where the same hour repeats endlessly. The adjustment procedure has no way of knowing whether the adjustment has already been done, no way to know that the RTC is already in standard time, and so proceeds to set the clock back one hour, hour after hour.
Having a flag is no better if there's no agreement amongst different
operating systems where it is.
Windows NT stores its flag in the registry,
in the ActiveTimeBias value of the
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation
key. But, of course, multiple copies of Windows NT will each have their
own registries, all with their own separate copies of this flag. So
bootstrapping multiple operating systems will result in the same
adjustment being applied multiple times. (This is made worse if the
different operating systems are configured to use different switchover
rulesets, or if one does things like backing up and restoring that part of
the registry.)
Multiple instances of the same operating system are but one variant of this. DOS+Windows 9x stored a similar flag in its registry, too. The problem of DOS+Windows 9x and Windows NT 2000 not sharing a single machine-wide flag, but each instead using their own registries, was reported on by Bruce E. Wampler in 1996 and again by Paul Schrieber in 2002 (and yet again by Colin Andrew Percival in 2002). Again, the behviour is that automatic changes to the hardware RTC are applied cumulatively by the individual operating systems, resulting in a clock that is incorrectly several hours ahead or behind where it should be.
One might think to allocate one of the unused non-volatile registers that
MC146818 provides, and simply use it for such a flag. Storing the flag on
the chip itself, in areas that the chip itself provides for non-volatile
storage, seems like an obvious answer. Unfortunately, there's a good
reason that Windows NT didn't take this fairly obvious approach. As those
who have read the CMOS.LST document in
Ralf Brown's Interrupt List
will already know, there's no standardization of NVRAM register contents
(each firmware manufacturer having its own ideas about what is stored in
which NVRAM register) and most NVRAM registers already have between two
and six different meanings (varying by firmware manufacturer).
The second basic problem is another simple one: A hardware real-time clock in normal operation produces time values, twice a year, that are either ambiguous or impossible values for local time.
For example: If DST changes occur at 01:00:00 standard time then the local time 01:30:00 doesn't exist on the day that local time changes from standard to daylight savings time. Yet a hardware RTC will yield such a time in the normal course of operation. Similarly, the local time 01:30:00 exists twice on the day that local time changes from daylight savings to standard time. It's impossible to know (because of the first basic problem) which time is being represented by a hardware RTC when it reads 01:30:00 on that day.
There is no way to program an MC146818 RTC to apply (an arbitrary country's) DST changes itself. (The MC146818 had a circuit to apply DST changes. It only applied the United States DST rules, and only worked correctly for a mere three years before the law changed. It's been useless for this purpose for a quarter of a century.) In the normal course of operation a hardware RTC yields a non-repeating, uniformly increasing, value. Local time simply doesn't work this way, and it's impossible to correctly, and unambiguously, map values from the hardware into a consistent local time value.
UTC does work this way, if we ignore leap seconds. (TAI doesn't have leap seconds and definitely works this way. But that's another discussion.) As reported by Len Spyker in 2007 a hardware RTC simply never yields unambiguous or impossible values if it is taken to be running in UTC (or, better, TAI) rather than local time. As Spyker also noted, bootstrapping a DOS Think operating system during the periods where the hardware RTC yields values that are ambiguous or impossible local times will yield behaviour that varies according to how one's particular operating system has chosen to guess at the actual local time in such circumstances. There are various guessing strategies possible, which yield differing results.