Paul Hill, August 2004
The Java VM relies on the underlying OS which relies on the hardware for its clock value. Since the millisecond value is supposed to be GMT, again to the limit of the machine, assuming the underlying hardware counts up, the answer is yes, the java.util.Date millisecond value will be an ever increasing sequence.
But you can run one of those SNTP synchronizers that keeps your OS/hardware clock sync'ed and you might think this might have the potential of correcting the system clock into the past and thus effect a java millisecond value. I know I thought this might be the case. But does SNTP reset clocks in reverse? The answer is no. According to RFC 1305, NTP never sets the clock backwards. Changes in that direction are achieved by updating the system clock more slowly, so that correct time catches up with your machine.
From rfc1305:
"The effect is to slew the clock to a new value at a small, constant rate, rather than incorporate the adjustment all at once, which could cause the clock to be set backward."
This quote is taken from the section on the Unix Clock Model, but apparently this is the behavior followed by other implementations on other OSes of the SNTP/NTP standard.
Therefore even running SNTP, which can fiddle with your system clock,
will not 'time warp' the time into the past, so millisecond times in the
JVM derived from System.currentTimeMillis() are guaranteed to be increasing.