間日期數據類型

時間日期是經常遇到的數據類型，Qt中時間日期類型的類如下。

• QTime：時間數據類型，僅表示時間，如15:23:13。
• QDate：日期數據類型，僅表示日期，如2017-4-5。
• QDateTime：日期時間數據類型，表示日期和時間，如2017-03-23 08:12:43。

時間日期轉換為字符串使用QDateTime的toString()函數，分別用不同的格式顯示時間、日期、日期時間。toString()的函數原型是：

QString QDateTime::toString(const QString &format) const

它將日期時間數據按照format指定的格式轉換為字符串。format是一個字符串，包含一些特定的字符，表示日期或時間的各個部分，下圖是用于日期時間顯示的常用格式符。

在設置日期時間顯示字符串格式時，還可以使用填字符，甚至使用漢字。例如，日期顯示格式可以設置為：toString ("yyyy年MM月dd日"），這樣得到的字符串格式是“2023年03月15日”。

同樣的，也可以將字符串轉換為QTime、QDate或QDateTime類型，使用靜態函數QDateTime::fromString()，其函數原型為：

QDateTime QDateTime::fromString(const QString &string, const QString &format)

其中，第1個參數string是日期時間字符串形式，第2個參數format是字符串表示的格式。

時間日期界面組件

Qt中有專門用于日期、時間編輯和顯示的界面組件，介紹如下。

• QTimeEdit：編輯和顯示時間的組件。
• QDateEdit：編輯和顯示日期的組件。
• QDateTimeEdit：編輯和顯示日期時間的組件。
• QCalendarWidget：一個用日歷形式選擇日期的組件。

QDateEdit和QTimeEdit都從QDateTimeEdit繼承而來，實現針對日期或時間的特定顯示功 能。實際上，QDateEdit和QTimeEdit的顯示功能都可以通過QDateTimeEdit實現，只需設置好屬性即可。

QDateTimeEdit類的主要屬性的介紹如下。

示例

在圖中窗體左上方的“日期時間”中，使用QTimeEdit、QDateEdit、QDateTimeEdit組件作為時間、日期、日期時間編輯器；在其下方，放置一個QLineEdit組件用于字符串顯示日期時間。界面如下圖。

1. 日期時間數據的獲取與轉換為字符串

“讀取當前日期時間”按鈕的clicked()信號的槽函數代碼如下：

void Widget::on_btnGetTime_clicked()
{
  QDateTime curDateTime=QDateTime::currentDateTime();
  ui->timeEdit->setTime(curDateTime.time());
  ui->dateEdit->setDate(curDateTime.date());
  ui->dateTimeEdit->setDateTime(curDateTime);
  ui->edtDateTime->setText (curDateTime.toString("yyyy-MM-dd hh:mm:ss"));
}

首先用QDateTime類的靜態函數currentDateTime()獲取當前日期時間，并賦值給變量curDateTime。

然后用curDateTime變量設置界面上3個日期、時間編輯器的時間或日期值，利用了 QDateTime的time()和date()分別提取時間和日期。

最后，將curDateTime表示的日期時間數據轉換為字符串然后在LineEdit編輯框上顯示。

2. 字符串轉換為日期時間

在程序運行時，手工修改“字符串顯示”后面文本框里的日期時間字符串，單擊“設置日期時間”按鈕，可以將文本框里的字符串轉換為QDateTime變量，并設置為組件的日期時間數據，代碼如下：

void Widget::on_btnSetTime_clicked()
{
  QString str=ui->edtDateTime->text();
  str=str.trimmed();
  if(!str.isEmpty())
  {
    QDateTime datetime=QDateTime::fromString(str,"yyyy-MM-dd hh:mm:ss");
    ui->timeEdit->setTime(datetime.time());
    ui->dateEdit->setDate(datetime.date());
    ui->dateTimeEdit->setDateTime(datetime);
  }
}

3. QCalendarWidget日歷組件

圖中窗體右側是一個QCalendarWidget組件，它以日歷的形式顯示日期，可以用于日期選擇。

QCalendarWidget有一個信號selectionChanged()，在日歷上選擇的日期變化后會發射此信號，為此信號創建槽函數，編寫代碼如下：

近在編程中遇到了時間與時區相關的問題，整理在這里

我的程序是一個在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 | Key| Default | 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
2011年12月 04日 星期日21:22:24CST
[admin@localhost]$ date -d@1323004944 -u
2011年12月 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()/1000+ 8 * 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
2011年12月 05日 星期一05:22:24CST

得到了一個完全錯誤的結果！

但如果用戶將這個 1323033744 按照UTC時區來解析后得到的結果是：

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

為了方便對比，把 1323004944 的解析結果也拿來對比

[admin@localhost]$ date -d@1323004944
2011年12月 04日 星期日21:22:24CST
[admin@localhost]$ date -d@1323004944 -u
2011年12月 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時間