<snip>
OK. You're correct in your pedantry; it does not assert that the time
output by
these services corresponds to the input values -- it guarantees only the
format.
I still feel that statements such as this entice a programmer to that
misbelief.
</snip>
You have been saying the same thing for years, with no one apparently
agreeing with you.
The "time output by these services" corresponds exactly to the input
values, according to an architectural definition. That is what you have
been told you multiple times. , There is an assumption of using the
standard epoch (if that assumption is not mentioned, I'd support
mentioning it).
<snip>
Would you be willing to see added to this description a caution such as:
Note: if the (E)TOD clock is set according to IBM's recommendation,
the times output by STCKCONV and CONVTOD do not match the input
values, but may differ according to the content of various common
control blocks.
?
</snip>
No I would not. Because it is not true, unless I am misunderstanding.
<snip>
What was the objective of providing these two services?
</snip>
I do not know. They meet the needs of whoever is using them currently.
<snip>
They give correct results only for dates before 1972, and I see little
value in that.
</snip>
I believe that they give correct results in 100% of cases. I think that it
is your use of "correct" that is not correct.
I have already mentioned being willing to document that leap seconds are
not taken into account.
Anyone who needs leap seconds to be taken into account can adjust their
STCK value accordingly.
If you were to ask for a system service that would do that adjustment,
under the assumption of use of the standard epoch, a service that would be
adjusted every time a leap second is added, that would be reasonable. I
suspect (without knowledge) that there already are ways of getting that
done either through LE or USS. Of course "reasonable" does not equate to
"likely to happen"
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN