long time=System.currentTimeMillis();
System.out.println("time="+time);

运行的结果为： time=1333097093625
我不知道这个结果的时间是怎么解释，看不懂。

System.currentTimeMillis()，它返回从 UTC 1970 年 1 月 1 日午夜开始经过的毫秒数。这个方法非常有用，特别 是它在各个版本的 Java 平台上都有。
currentTimeMillis() 的一个问题是，它虽然是以毫秒计数返回时间，但是不能保证返回的计数的粒度或精度。在一些系统上，时间是真正的毫 秒计数，大约每一毫秒改变一次。在另一些系统上，时间可能每隔 10 或 20 毫秒才变一 次，因此每一次的精度都可能变化。
另一个局限是在方法定义中的基本时间单位。当 Java 平台第一次开始使用时，一毫秒仍然是相当短的时间间隔（特别是对于解释语言）。今天，随着 CPU 时钟速度比第一次发布 Java 平台时快了近一百倍，一毫秒已经成了相对长的一段时间。
除了 currentTimeMillis() 的这些问题， 还有另一个使用任何类型的计时器方法监视程序执行都会有的问题。这个问题是计时器方法本身 —— 可能要深入操作系统才能访问计时器 —— 这增加了一些开销，如果计时器方法开销过大（或者方法调用过于频繁），那么就会严重扭曲计时测量。为了明智地使用我们的性能跟踪方面，我需要至少大体知道计时器方法调用增加 了多少开销。

是以毫秒计数返回时间

返回以毫秒为单位的当前时间。
注意，当返回值的时间单位是毫秒时，值的粒度取决于底层操作系统，并且粒度可能更大。例如，许多操作系统以几十毫秒为单位测量时间。

首先System.currentTimeMillis()产生一个当前的毫秒，这个毫秒其实就是自1970年1月1日0时起的毫秒数，Date()其实就是相当于Date(System.currentTimeMillis());因为Date类还有构造Date(long date)，用来计算long秒与1970年1月1日之间的毫秒差。 得到了这个毫秒数，我们自己也可以算起现在的年月日周时，但是这不是我们去计算的，因为有Calendar。Calendar最终出的结果就是年月日周时时区。