日戳 时区 java mysql

By admin in 天文台 on 2018年9月28日
  • 当一个岁月
    比如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

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图
Copyright @ 2010-2018 亚洲必赢手机官网 版权所有