If you do not use the CURRENT-DATE function in COBOL II/iX, or if you do not
change time zones by altering the value of the TZ variable while a program
is executing, feel free to skip the rest of this article.

The strangeness.

A couple of weeks ago Shawn Gordon made an observation about a strangeness
in the way the CURRENT-DATE function responds to a change in the TZ
variable.  If the value of the TZ variable changes between two calls to
CURRENT-DATE, the date and time returned by the second call reflect the new
TZ value, but the time differential factor in character positions 17-21 does
not.  Shawn's observation is correct.  I'll try to explain what's going on.

What the rules say (and don't say).

The rules of COBOL define the layout of the 21-character alphanumeric value
returned by the CURRENT-DATE function, including the format of the time
differential factor, which reports the difference between the local time
indicated and Greenwich Mean Time (now known as Coordinated Universal Time,
UTC).  However, there is no standard way of specifying what time zone the
function should use, and there are no rules about whether it should be
possible for the time zone to change while a program is executing.  Those
details are left up to the particular implementation of COBOL.  The
reference manual for COBOL II/iX explains how to use the session-level
variable TZ to specify the local time zone, but does not discuss what you
should expect to happen if you change the value of TZ "on the fly."

What is happening.

The CURRENT-DATE function makes calls to the C/iX library functions
localtime() and gmtime().  The value returned by localtime() is formatted
into the local date and time that are returned in character positions 1-16.
On the first call only, CURRENT-DATE also calls gmtime(), and the time
differential factor is derived from the difference between the values
returned by localtime() and gmtime().  This time differential factor is
returned in character positions 17-21 and is saved and returned for all
future calls to CURRENT-DATE during this execution of the program.  It is
implicitly assumed that the time differential factor will not change during
program execution.  This is why changing TZ has no effect on the time
differential factor unless the program is restarted.

The localtime() function, however, does check the value of TZ every time it
is called.  That might be considered unfortunate from a performance
standpoint, because of the overhead on MPE/iX of repeated calls to the
HPCIGETVAR intrinsic.  But it is a requirement of the POSIX standard.  POSIX
explicitly allows an application that uses localtime() to change TZ and have
the changed TZ apply to itself.

So the COBOL II/iX library is trying to be efficient, the C/iX library is
being extravagant, and the result is inconsistent behavior.

Bottom line.

I would agree that this is a bug, although I don't know that anyone actually
uses the time differential factor.  I think Shawn is the first person to
notice it.  Fixing it will introduce a slight performance penalty, but it
probably ought to be done.  I will put it on my list of things to fix.  If
it actually matters enough to anybody to submit a Change Request (SR) on
this, it will greatly increase the probability of it getting done in a
timely fashion.

Walter Murray
Hewlett-Packard
Support Services
Languages and Current Products
COBOL II/iX project

* To join/leave the list, search archives, change list settings, etc *
*     please visit http://raven.utc.edu/archives/hp3000-l.html       *