• 时间戳 时区 java mysql


    • 当一个时间 比如2016年5月6日,生成时间戳。这个运算是与时区有关的。首先得确认这个时间是哪个时区的,然后转换成utc时区的时间。再减去1970,得到的秒数,就是时间戳。
    • 时间戳是个一定的值,他与时区没关。
    • 当想把时间戳还原成时间,必须指定时区,才能确认什么时间。
    • 总结:时间与时区有关。时间戳与时区无关,它是utc,也就是gmt时区的时间与1970年的差。在时间轴的某一点时刻,不管位于哪个时区(如北京 +8小时,或者格林威治 +0小时),它转换成的时间戳是相等的。
    • 首先澄清一个概念:

    所有的linux系统文件系统底层存储的都是UTC时间,也就是说都是自1970年0时0分0秒以来的UTC标准时间的秒数。

    无论系统配置是什么时区,显示如何不同,底层存储都是一致的。

    • 如何得到UTC系统时间?

    在shell环境下 >date '+%s' 即可得到

    在mysql环境下>select unix_timestamp();即可得到

    • timestamp是什么?
    timestamp是mysql数据库中的一种字段类型,
    不用说太多,
    • 内部存储是4个字节
    • 精度达到微妙
    • 回转换成UTC时间存储
    • 读取的时候再根据时区转换回来

    mysql> select now()+0;
    +-----------------------+
    | now()+0               |
    +-----------------------+
    | 20130722184134.000000 |
    +-----------------------+
    1 row in set (0.00 sec)


    mysql> select now();  
    +---------------------+
    | now()               |
    +---------------------+
    | 2013-07-22 18:41:37 |
    +---------------------+
    1 row in set (0.00 sec)
    可以看到,我们看到的timestamp实际是已经根据当前时区转换过格式的字符形式
     
    • 如何在mysql中根据timestamp得到UTC系统时间戳呢呢?
    很简单,mysql> select unix_timestamp( 20130722183356.000000);
    +----------------------------------------+
    | unix_timestamp( 20130722183356.000000) |
    +----------------------------------------+
    |                             1374489236 |
    +----------------------------------------+
                 
    • 如何在mysql中根据UTC 系统时间戳得到当前时区的timestamp呢?
    mysql> select from_unixtime(1374489236);
    +---------------------------+
    | from_unixtime(1374489236) |
    +---------------------------+
    | 2013-07-22 18:33:56       |
    +---------------------------+
    1 row in set (0.00 sec)
     
    •  如何在mysql中根据当前时区的时区得到其他时区的timestamp呢?
    mysql> SELECT CONVERT_TZ('2013-07-22 18:41:37','+08:00','+00:00') as UTC;         
    +---------------------+
    | UTC                 |
    +---------------------+
    | 2013-07-22 10:41:37 |
    +---------------------+
    1 row in set (0.00 sec)
    • 一个罕见的问题

    数据库使用Amazon RDS 是无法修改时区的,统一使用UTC时区

    应用程序使用Amazon 服务器 是UTC -7 美西时间

    数据库部分时间字段使用了current_timestamp,使用了UTC时区

    部分字段使用了unix_time,由应用程序插入,理论上也是UTC时间

    部分字段使用了unix_time并根据app服务器的时区转成了时间的string格式,导致出现UTC-7的时间

    导致了同一IDC的数据有了两种时间

    ===========================================

    结论:

    我们不需要被timestamp和时区弄糊涂,其实很简单,timestamp存储的时间是带时区偏移的。

    所有的数据库的时间应该统一操作,要么使用DB的current_timestamp,要么使用应用程序插入。

    在有多IDC且不同时区的情况下,

    如果需要标准UNIX时间戳:我建议只需要每次取出UTC的时间戳进行处理

    如果需要标准的timestamp,我建议全部统一convert到一个时区去处理

     
    0

    (摘自http://www.cnblogs.com/flying5/archive/2011/12/05/2276578.html)

    最近在编程中遇到了时间与时区相关的问题,整理在这里

      我的程序是一个在Hadoop上运行的分布式程序,从MySQL数据库中取数据,经过处理之后输出

    一. 基本概念

      时区 :time zone 1884年国际经线会议规定,全球按经度分为24个时区,每区各占经度15°。

          以本初子午线为中央经线的时区为零时区,由零时区向东、西各分12区,东、西12区都是半时区,共同使用180°经线的地方时。

      CST :China Standard Time UTC+8:00 中国标准时间(北京时间),在东八区

      UTC :Universal Time Coordinated,世界协调时间,又称世界标准时间、世界统一时间。UTC 提供了一种与时区无关(或非特定于时区)的时间。

          世界上的所有时区都可以表示为 UTC 加上或减去一个偏移量。

          因此,UTC是0时区的时间,如北京为早上八点(东八区),UTC时间就为零点,时间比北京时晚八小时

      GMT :Greenwich Mean Time格林威治标准时间,指位于英国伦敦郊区的皇家格林尼治天文台的标准时间,因为本初子午线被定义在通过那里的经线。

      Unix timestamp :Unix时间戳,或称Unix时间(Unix time)、POSIX时间(POSIX time),是一种时间表示方式,

          定义为从格林威治时间(UTC/GMT的午夜)1970年01月01日00时00分00秒起至现在的总秒数。

      可以这么说:

      UTC和GMT几乎是同一概念,两者的区别是GMT是一个天文上的概念,UTC是基于原子钟。

      GMT=UTC

      GMT + 8 = UTC + 8 = CST

      UTC+时间差=本地时间 (时间差东为正,西为负,东八区记为 +0800)

    二. 从数据库取数据的过程

      mysql>select auction_id,startsfrom auctions where auction_id=88888;
    +-------------+---------------------+
    | auction_id  | starts |
    +-------------+---------------------+
    | 88888       | 2011-10-24 20:32:58 |
    +-------------+---------------------+
    1 rowin set (0.00 sec)
     
    mysql> show columnsfrom auctions;
    +--------------------------------+---------------+------+-----+---------+-------+
    | Field | Type |Null KeyDefault | Extra |
    +--------------------------------+---------------+------+-----+---------+-------+
    |starts | datetime | YES | MUL |NULL | |

      可见:数据库的时间字段starts存的是datetime类型,它是一个和时区相关的string(显然:string都是和时区相关的)

      而且数据库是按照CST时区存的时间

         程序中从数据库取数据用的sql语句:

    mysql>select auction_id,DATE_FORMAT(starts,'%Y%m%d%H%i%S')from auctions where auction_id=88888;
    +-------------+------------------------------------+
    | auction_id  | DATE_FORMAT(starts,'%Y%m%d%H%i%S') |
    +-------------+------------------------------------+
    | 88888       | 20111024203258 |
    +-------------+------------------------------------+
    1 rowin set (0.00 sec)

      这里只是简单的用DATE_FORMAT函数把datetime类型的starts字段转换为我们需要的格式 %Y%m%d%H%i%S 而已

    三、Java代码

      看这样一段转换时间的java代码:

    // 将字符串时间转化为秒数(yyyyMMddHHmmss)
    staticpublic long getUnixTimestamp(String srcTime)
    {        
              SimpleDateFormat sdf =new SimpleDateFormat("yyyyMMddHHmmss");
              Date result_date;
              longresult_time = 0;
              try
                       result_date = sdf.parse(srcTime);
                       //返回的是毫秒数故除以1000
                       result_time = result_date.getTime()/1000;
              }catch (Exception e) { 
                       //出现异常时间赋值为20000101000000
                       result_time =946684800;
              }
              returnresult_time;
     }

      计算结果:

    getUnixTimestamp("20111204212224") =1323004944

      说明:java.util.Date中的getTime函数定义如下:

         java.util.Date代表一个时间点,其值为距公元1970年1月1日 00:00:00的毫秒数。所以它是没有时区和Locale概念的。

         public long getTime() 返回自 1970 年 1 月 1 日 00:00:00 GMT 以来此 Date 对象表示的毫秒数

      java中通过如下形式取得当前时间点: 

    Date now =new Date(); //这个时间点与本地系统的时区无关

      而正因为其与时区的无关性,才使得我们的存储数据(时间)是一致的(时区一致性)。
      一般的我们将now存储于数据库中,当我们需要展现数据时,将now格式化成想要的格式,如:2011-12-04 21:22:24
      而这个功能一般交由java.text.DateFormat来实现。例如:

    SimpleDateFormat sdf =new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    String snow = sdf.format(now);

      我们发现snow是带时间(如2011-12-04 21:22:24)的字符串,那么 2011-12-04 21:22:24 这个时间是哪个时区的时间呢?

      默认情况下,SimpleDateFormat 取得本地系统的时区(我的时区为GMT+8北京),然后按照 pattern("yyyy-MM-dd HH:mm:ss")格式化now,
      此时输出的就是 GMT+8 区的时间了。如果想支持国际化时间,则先指定时区,然后再格式化date数据。例如:

    SimpleDateFormat sdf =new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    sdf.setTimeZone(TimeZone.getTimeZone("GMT+8"));
    String snow = sdf.format(now);// snow = 2011-12-04 21:22:24
    sdf.setTimeZone(TimeZone.getTimeZone("GMT+7"));
    String snow2 = sdf.format(now);// snow2 = 2011-12-04 20:22:24 (可见:东八区比东七区早一个小时)

      另外,你可以通过如下代码修改本地时区信息:

    TimeZone.setDefault(TimeZone.getTimeZone("GMT+8"));

      在windows操作系统中,是通过桌面右下角,也可以指定操作系统的时区。

      在linux系统中,通过如下命令可以得到当前时区

    [admin@localhost]$ date -R
    Sun,04 Dec 201122:49:00+0800

    四、结论:

      getTime()返回的已经是一个UTC的unix timestamp秒数了,与时区无关;而转换为字符串后,就和时区相关了
      对于这个秒数,不同时区的人,按照自己所在的时区去解析,就可以得到正确的时间了

    [admin@localhost]$ date -d@1323004944
    201112月 04日 星期日21:22:24CST
    [admin@localhost]$ date -d@1323004944 -u
    201112月 04日 星期日13:22:24UTC

      对于涉及到时间转换的程序来说,如果代码里面没有强行指定时区,那就会依赖于操作系统的时区。

      特别是对于分布式程序,如果不同机器上系统时区不一样,那就会出现不一致的数据了!

    五、对unix timestamp和时区概念的曲解和误用

      由于历史原因,发现程序中有这样一段代码:

    // 将字符串时间转化为秒数(yyyyMMddHHmmss),有8个小时的时差
      staticpublic long getLongTime(String srcTime)
      {        
                SimpleDateFormat sdf =new SimpleDateFormat("yyyyMMddHHmmss");
                Date result_date;
                longresult_time = 0;
                try
                         result_date = sdf.parse(srcTime);
                         //返回的是毫秒数故除以1000
                         result_time = result_date.getTime()/10008 3600;  // 这里加了八个小时
                }catch (Exception e) { 
                         //出现异常时间赋值为20000101000000
                         result_time =946684800;
                }
                 
                returnresult_time;
       }

      计算结果:

    getUnixTimestamp("20111204212224") =1323033744

      显然,这个时间比上面通过 getUnixTimestamp("20111204212224") = 1323004944 得到的时间多了8个小时

           1323033744 - 1323004944 = 28800 = 8 * 3600 = 8h

      如果用户将得到的 1323033744 按照自己所在的时区解析后得到的结果是:

    [admin@localhost]$ date -d@1323033744
    201112月 05日 星期一05:22:24CST

      得到了一个完全错误的结果!

      但如果用户将这个 1323033744 按照UTC时区来解析后得到的结果是:

    [admin@localhost]$ date -d@1323033744 -u
    201112月 04日 星期日21:22:24UTC

      为了方便对比,把 1323004944 的解析结果也拿来对比

    [admin@localhost]$ date -d@1323004944
    201112月 04日 星期日21:22:24CST
    [admin@localhost]$ date -d@1323004944 -u
    201112月 04日 星期日13:22:24UTC

      可以看到,这个代码中得到的秒数时间是比UTC的unix timestamp秒数多了八个小时

        这个时间 1323033744 可以理解为北京时区得到的秒数,但是不是unix timstamp时间!

        unix timestamp秒数是与时区无关的,不管是在哪个时区得到的unix timestamp都是一样的

      我们可以验证一下,用北京时间“20111204212224”减去“19700000000000”得到的秒数,就是 1323033744

    SimpleDateFormat df =new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    java.util.Date end = df.parse("2011-12-04 21:22:24");
    java.util.Date start = df.parse("1970-01-01 00:00:00");
    longdelta = (end.getTime() - start.getTime())/1000;
    System.out.println("delta="+ delta); // delta=1323033744

      或者用shell命令来求时间差

    [admin@localhost]$ date -d"2011-12-04 21:22:24" +%s
    1323004944
    [admin@localhost]$ date -d"1970-01-01 0:0:0" +%s
    -28800
    [admin@localhost]$ date -d"2011-12-04 21:22:24" +%s -u
    1323033744
    [admin@localhost]$ date -d"1970-01-01 0:0:0" +%s -u
    0

        1323004944 + 28800 = 1323033744

      对于东八区的人来说,1323033744 这个时间按照UTC时间可以解析正确。不能按照自己所在的时区去解析,不然就是错的

      但是如果是东七区的人呢?需要按照UTC时间解析后,自己去减1个小时的时差,so ugly!

      所以,用户在解析1323033744 这个数据的时候:

        (1) 按照UTC时间来解析得到北京时间,然后根据时间差换算成自己所在时区的时间

            (当然,一般都是在北京时区了,所以不用换算,按UTC时间来解析就能得到正确的时间)

        (2) 将这个时间减去8小时得到unix timestamp,然后按照自己所在的时区去解析就可以了

      总结:这段代码是对unix timestamp和时区的曲解和误用。

    六、从数据库获取unix timestamp时间

        其实从数据库是可以直接获取到unix timestamp时间的

    mysql> select auction_id,unix_timestamp(starts)  from auctions where auction_id=88888;                                                   
     +-------------+------------------------+
     | auction_id  | unix_timestamp(starts) |
     +-------------+------------------------+
     |88888       |            1319459578 |
     +-------------+------------------------+
     1row in set (0.02 sec)

    七、参考

      java.util.Date  http://www.jar114.com/jdk6/zh_CN/api/java/util/Date.html

      关于java Date和时区的问题  http://blog.163.com/haizai219@126/blog/static/444125552009101924912981/

    八、unix时间戳转换工具

    http://code.aosoo.com/unixtime

     
     
  • 相关阅读:
    PTA9
    PTA8
    第七周
    第六周
    第五周
    PTA4
    2019第三次作业
    第十周课程总结
    第九周课程总结&实验报告(七)
    第八周课程总结&实验报告(六)
  • 原文地址:https://www.cnblogs.com/bigben0123/p/6042985.html
Copyright © 2020-2023  润新知