If I remove the "#define 60" line in an unmodified posixmodule.c from
trunk, I get the following compiler error:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE  -c
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function posix_times:
./Modules/posixmodule.c:5964: error: HZ undeclared (first use in this
function)

So yes, HZ isn't available there. It sure is defined *somewhere* (grep
shows a definition in /usr/include/asm-x86_64/param.h), but it isn't
anywhere Python would pick it up.

And I don't really see why it should when the man pages all argue that
using HZ for times is for "older system" (this is a man page from 2002,
no less!). Can you measure a performance difference between your patch
and the old buggy behaviour? I couldn't, on any machine, and I'd be very
surprised if it existed. There is no significant difference between
dividing by a constant and diving by a static module variable, and, as
Antoine rightly suggests, any such difference would be completely lost
in the noise considering the hefty cost of the other operations.

Regarding your two issues:
1. Yes, the sysconf value should take precedence over HZ, since this is
what "man 2 times" says you should use.
2. Personally, I'd be just as fine with the original patch that doesn't
have the code complexity of the value caching, but I'm fine with
anything that fixes the bug. Keeping the old behaviour where possible
"for old time's sake" seems a bad idea -- there were at least two broken
platforms (Mac OS and Xeon), and there may be others. Using the
documented behaviour (sysconf) where available is a much better
solution; honestly, sticking to using HZ as a default without support
for that from any documentation has a cargo-cult programming smell to me.

I don't know if there are platforms that have times, but neither sysconf
nor HZ. That sounds very strange to me, but of course I can't rule it
out. But if there are, it is likely that os.times was broken before on
these platforms -- it was broken on two platforms that I wouldn't
consider minor. In that case, it will still be broken, but at least now
we have a unit tests that detects this.