16 12
发新提问
打印

[基本语法] 用SimpleDateFormat将1900-01-01 8:00:00转化后相差5:52

用SimpleDateFormat将1900-01-01 8:00:00转化后相差5:52

import   java.text.SimpleDateFormat;
public   class   aaa   {
             public   static   void   main(String[]   args)   throws   Exception   {
             String   value   =    "1900-01-01   8:00:00 ";
             long   iii   =   new   SimpleDateFormat( "yyyy-MM-dd   HH:mm:ss ").parse(value).getTime();
             java.sql.Timestamp   xx   =   new   java.sql.Timestamp(iii);
             System.out.println(xx.toString());
}
输出结果1900-01-01   08:05:52
相差了5:52秒
  
经试验发现1900-01-01   8:00:00   至   8:00:05   会相差5:52   ,   其他日期时间无误。为什么?难道是jdk的bug   ,望大侠指点!!不甚感激
赏金: 10 疯狂金币     剩余: 10 疯狂金币    

TOP

公司里外包给别人的一个项目里碰到这个问题,对方的兄弟也不知道为什么?但用另一个方式解决了,那位兄台说一下?

只是1900 的有问题..而且是08:00的才有问题,其它的都没有问题的

TOP

唉,论坛里越来越少人来回答问题了

TOP

我正在看,一会就贴上来。
太好玩了这个
Don't give me any chance!
身挑一狙,独行天下!

TOP

我在程序中加了一些输出如下:
复制内容到剪贴板
代码:

import java.text.SimpleDateFormat;
public class AAA{
    public static void main(String[] args){
        String value = "1900-01-01 08:05:50";
    System.out.println("value = " + value);
       try{
         long iii = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").parse(value,new java.text.ParsePosition(0)).getTime();
        System.out.println("iii   = " + iii);
        java.sql.Timestamp xx = new java.sql.Timestamp(iii);
       System.out.println("xx    = " + xx.toString());
      }catch(Exception e){
      System.out.println(e);
  }
}
}
当value=1900-01-01 08:00:00时

当value=1900-01-01 08:05:52.0时

可以看出这两种情况中的iii值是一样的,为-2208988800000
Date类的getTime()函数的返回值是:自 1970 年 1 月 1 日 00:00:00 GMT 以来此 Date 对象表示的毫秒数。
也就是说以上两个时间点到1970 年 1 月 1 日 00:00:00 GMT的毫秒数是一样的,这个肯定是不对的

接着我又把value改为1900-01-01 08:05:53也就是比1900-01-01 08:05:52.0多一秒。
这两个时间和1970 年 1 月 1 日 00:00:00 GMT相差应该是1000毫秒。

1900-01-01 08:05:53的iii为:  -2208988799000
与1900-01-01 08:05:52.0的iii: -2208988800000
相差正好是1000,这是对的。

当时间为1900-01-01 07:59:59时

这时的iii为:               -2208988801000
1900-01-01 08:00:00的iii为:-2208988800000
也正好相差1000,也是对的。

当时间为1900-01-01 08:00:01时

这时的iii为:-2208988799000

我加了几组数据,对比一下:
1900-01-01 07:59:59时的iii为:-2208988801000,xx为:1900-01-01 07:59:59.0
1900-01-01 08:00:00时的iii为:-2208988800000,xx为:1900-01-01 08:05:52.0
1900-01-01 08:00:01时的iii为:-2208988799000,xx为:1900-01-01 08:05:53.0
1900-01-01 08:05:51时的iii为:-2208988449000,xx为:1900-01-01 08:11:43.0
1900-01-01 08:05:52时的iii为:-2208988800000,xx为:1900-01-01 08:05:52.0
1900-01-01 08:05:53时的iii为:-2208988799000,xx为:1900-01-01 08:05:53.0
1900-01-01 08:05:54时的iii为:-2208988798000,xx为:1900-01-01 08:05:54.0
通过对比,发现从1900-01-01 07:59:59到1900-01-01 08:05:54竟然发生了时间倒流!!!
当过到1900-01-01 08:05:51时,这时的下一秒的iii应该为:-2208988448000。
但1900-01-01 08:05:52的iii竟为:-2208988800000。
当过到过到1900-01-01 08:05:52时,又回到了1900-01-01 08:00:00。太可怕了!!!

但当我们回忆那段时间的时候,时间竟然又消失了。
当我们从1900-01-01 08:05:52.0想它的前一秒的时候。
发现的竟然不是1900-01-01 08:05:51而是1900-01-01 07:59:59。
中间竟有5分52秒不存在了。

这究竟是什么原因引起的呢,是历史就是这样发生的,还是JDK的Bug造成的时间逆转。
我不知道其中的原因,还等待高手来解答!

[ 本帖最后由 awp 于 2010-1-7 11:17 编辑 ]
附件: 您所在的用户组无法下载或查看附件
本帖最近评分记录
  • heyitang 疯狂金币 +10 熱心版主 2010-1-7 12:18
Don't give me any chance!
身挑一狙,独行天下!

TOP

我在API里面看到些内容:
尽管 Date 类打算反映协调世界时 (UTC),但无法做到如此准确,这取决于 Java 虚拟机的主机环境。当前几乎所有操作系统都假定 1 天 = 24 × 60 × 60 = 86400 秒。但对于 UTC,大约每一两年出现一次额外的一秒,称为“闰秒”。闰秒始终作为当天的最后一秒增加,并且始终在 12 月 31 日或 6 月 30 日增加。例如,1995 年的最后一分钟是 61 秒,因为增加了闰秒。大多数计算机时钟不是特别的准确,因此不能反映闰秒的差别。

秒由 0 至 61 的整数表示;值 60 和 61 只对闰秒发生,尽管那样,也只用在实际正确跟踪闰秒的 Java 实现中。于按当前引入闰秒的方式,两个闰秒在同一分钟内发生是极不可能的,但此规范遵循 ISO C 的日期和时间约定。
Don't give me any chance!
身挑一狙,独行天下!

TOP

唉,兄台扬扬刷刷写了那么多,还以为你搞定了呢

TOP

呵呵,这个真没搞定,不过值得一搞。
我感觉应该是JDK的问题。

[ 本帖最后由 awp 于 2010-1-7 14:05 编辑 ]
Don't give me any chance!
身挑一狙,独行天下!

TOP

引用:
原帖由 大块头 于 2010-1-7 12:40 发表
唉,兄台扬扬刷刷写了那么多,还以为你搞定了呢
哦,人家awp也把你测试了半天!一个谢字也没有?兄台说 这话也不厚道了吧!
其实,这个问题,应该多半是JDK的bug了的。。
成功的人不是赢在起点,而是赢在转折点!

TOP

顶一顶。。。。。。。。。。。。。。。。

TOP

 16 12
发新提问
版块跳转  最近访问的版块