DH> I find it hard to believe that *every* programmer is querying the RTC
 DH> rather than using the DosQuerySysInfo API function.

You may find it hard to believe, but it's nevertheless largely true.  They use 
DosGetDateTime(), which is a function that reads the "raw" hardware clock,
rather than DosQuerySysInfo() which reads the 64-bit clock provided by the
OS/2 kernel.  This is a "DOS think" legacy.  Application and compiler library
developers used to read the RTC hardware pretty much directly in DOS, and the
habit carried over into OS/2 application and compiler library development.

The irony is that this particular piece of "DOS think" even infects
development that otherwise has a strong UNIX background.  EMX C++, with its
roots in GNU compilers and UNIX traditions, would have been the prime
candidate for getting timekeeping right on 32-bit OS/2.  This is because
32-bit OS/2 keeps time in pretty much the same way as UNIX does.  But even EMX 
C++ uses DosGetDateTime() to read the hardware clock, alas!

( I did suggest at the beginning of this year that some enterprising EMX C++
hacker patch the EMX runtime library so that it works properly, by ripping out 
the DOS think code and putting in code to do things correctly.  They could
start with the GNU libc code and work from there.  The irony of EMX C++ is
that the GNU libc code for handling time, which EMX C++ *doesn't* use, would
actually pretty much work properly and do the right thing on 32-bit OS/2 with
little alteration. )

This whole subject was discussed at length in this echo at the beginning of
this year.  I won't go over it all again in this message, but will mention one 
thing:  You can compromise between having the OS/2 kernel keep time correctly
and the broken applications that were written with the "DOS Think" mindset. 
Simply keep your hardware RTC in local time and set your TZ environment
variable so that it indicates that your timezone is always offset 0 hours from 
UTC.  (For example, for Eastern Australian Standard Time use a TZ environment
variable value of, say, "EST0EDT0".)  The OS2CLU02 commands, and everything
else that uses 32-bit OS/2 as it was actually designed to work, will calculate 
local time correctly, and the broken "DOS think" applications will also
calculate local time correctly.

Of course, there are several undesirable side-effects of this compromise: You
won't be able to run multiple programs in different timezones concurrently, as 
one *can* do if 32-bit OS/2's timekeeping mechanism is used as it was actually 
designed; file and directory timestamps won't be maintained in UTC and thus be 
portable from system to system independent of timezone (as they should be --
this is another little understood facet of 32-bit OS/2's timekeeping); and
*no* program will be able to calculate UTC correctly, so you will not be able
to use UTC at all should you desire to do so.

However, if you are prepared to live with the above side effects, this
compromise should be acceptable.

One more thing ...

 ¯ JdeBP ®

--- FleetStreet 1.22 NR