Timing Issues in Squeak and Pharo and Cuis Smalltalks

I was profiling yesterday, and discovered these issues:

Issue:
=====
Time and DateAndTime both show human-readable time information to
micro-second precision.  Time also holds information to nano-second
precision.

Both objects are only providing information to the nearest millisecond.

The digits beyond milliseconds are always (on my PC) filled in as '902'.

In the nanoseconds instvar of the Time objects, the nanoseconds are
always filled in as '000'.


Root cause:
=========
When Times (and DateAndTimes) are created, they use the
Time>>primUTCMicrosecondsClock method to generate the time

primUTCMicrosecondsClock
"Answer the number of micro-seconds ellapsed since Squeak epoch.
That is since 00:00 on the morning of January 1, 1901 UTC.
At least a 60-bit unsigned integer is used internally which is enough
for dates up to year 38435.
Essential. See Object documentation whatIsAPrimitive. "

<primitive: 240>
self primitiveFailed

Potential for solution:
================
[The following is taken from Stack Overflow,
http://stackoverflow.com/questions/2607263/how-precise-is-the-internal-clock-of-a-modern-pc]
Modern PCs have a hardware  High Precision Event Timer (HPET) which
specifies a clock speed of 10MHz
http://www.intel.com/hardwaredesign/hpetspec_1.pdf
Even newer PC architectures take this and put it on the Northbridge
controller and the HPET can run at 100MHz or even greater. At 10Mhz we
should be able to get a resolution of 100 nano-seconds and at 100MHZ
we should be able to get 10 nano-second resolution.

The following operating systems are known not to be able to use HPET:
Windows XP, Windows Server 2003, and earlier Windows versions, older
Linux versions
The following operating systems are known to be able to use HPET:
Windows Vista, Windows 2008, Windows 7, x86 based versions of Mac OS
X, Linux operating systems using the 2.6 kernel and FreeBSD.