On 09-16-1999, Jonathan de Boyne Pollard wrote to Darren Hamilton
about Os2clu02 & Utc.

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

Too bad. This "DOS-think" probably undermines many aspects of a
mutitasking OS.  :-(



JP> ( I did suggest at the beginning of this year that some 
JP> enterprising EMX C++ hacker patch the EMX runtime library 
JP> so that it works properly, by ripping out the DOS think 
JP> code and putting in code to do things correctly.  They 
JP> could start with the GNU libc code and work from there.  
JP> The irony of EMX C++ is that the GNU libc code for handling 
JP> time, which EMX C++ *doesn't* use, would actually pretty 
JP> much work properly and do the right thing on 32-bit OS/2 
JP> with little alteration. )
JP> 
JP> This whole subject was discussed at length in this echo at the
JP> beginning of  this year.  I won't go over it all again in this
JP> message,  but will mention one thing:  You can compromise between 
JP> having the OS/2 kernel keep time correctly and the broken 
JP> applications that were written with the "DOS Think"  mindset. 
JP> Simply keep your hardware RTC in local time and  set your TZ
JP> environment variable so that it indicates that  your timezone is
JP> always offset 0 hours from UTC.  (For  example, for Eastern
JP> Australian Standard Time use a TZ  environment variable value of,
JP> say, "EST0EDT0".)  The  OS2CLU02 commands, and everything else that
JP> uses 32-bit  OS/2 as it was actually designed to work, will
JP> calculate  local time correctly, and the broken "DOS think" 
JP> applications will also calculate local time correctly.

I remember this early 1999 thread but did not archive it for future
reference. Thank you for the workaround tip.

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

God I hate compromise.  ;-)

JP> One more thing ...
JP> 
JP>  > JdeBP <

Continued in the next message.

Internet e-mail: darrenah@interchange.ubc.ca

 * KWQ/2 1.2i * AMD Athlon: Proof that Intel isn't working hard enough.

--- Maximus/2 3.01