Hello Jonathan;

Here is the section of your INF documentation file that is relevant to
my problem:


 
Commands such as DIGCLOCK, SAYDATE, and TOUCH obtain the current date
and time from the OS/2 kernel using  its DosQuerySysInfo API function,
which yields a number giving the number of seconds since the start of
the year 1970.  This is a 64-bit number that can potentially last up to
the year 584 thousand million.  (The OS/2 kernel has no Year 2038
problem in this area.) 

The OS/2 kernel requires that the PC hardware real-time clock (RTC) be
set to Universal Time (UTC) for this to operate correctly.  The
hardware RTC must not be set to local time, and daylight savings time
changes must not be applied to it. 

Note:  Many OS/2 users set the hardware RTC to local time, and the
OS/2 kernel calculates UTC time incorrectly as a result.  Many OS/2
programs read the RTC directly and assume that it runs in local time
with daylight savings changes applied, rather than calling
DosQuerySysInfo for the time as they should.  (Such programs are
generally poor, however, since they also all too often ignore timezones
and the TZ environment variable as well.  All too often this is a
result of programmers thinking that they are still writing DOS
programs.)  But the correct configuration for OS/2, nonetheless, is for
the hardware RTC to run in UTC, the same as for PC UNIX, and linux,
systems. 



All commands will calculate the local time from the UTC time by
applying the timezone offsets and daylight savings time rules supplied
in the TZ environment variable.   



I set my RTC to UTC time.

I set my TZ as: SET TZ=PST8PDT7,M10.5,M4.1

Your utilities work flawlessly. All time queries report the correct
local time.

BUT:

Every other software on this system reports or displays UTC time as
the "local" time. This includes OS/2 Warp v3.0 (FP 40) time and date
functions, Filestar/2, KWQ Mail/2, ZOC/Pro v3.13, etc.

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

Is there something I have missed?

Regards,

Darren

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
3613/666