pg中存儲的是日期,形如:"2017-01-06 14:38:44"sql
查詢的時候要以時間戳的形式返回,形如:1483713524函數
經查詢,epoch函數能夠實現此功能,例如一下sql:spa
SELECT extract(epoch FROM valid_end_time) * 1000 , valid_end_time as valid_end_time FROM cms_policy_access WHERE valid_flag = 1 and type = '00101'
查出的結果以下:code
能夠看到,1483713524000就是此時間的一個時間戳格式(擴大了1000倍後)it
可是可能存在一個問題,時區問題,好比這裏的1483713524000,轉化爲時間格式以後爲:ast
2017-01-06 22:38:44class
與存儲的時間相比,增大了八個小時。百度
猜想緣由多是:date
此表cms_policy_access中的valid_end_time的格式是timestamp without time zone,epoch是根據其餘時區計算的時間戳,和本地的時區不一樣,致使了時間的間隔;語法
百度pg的手冊,裏面是使用EPOCH FROM TIMESTAMP WITH TIME ZONE的方式轉換的,好比:
SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE '2017-01-05 14:38:42');
獲得1483598322
通過轉換獲得的時間是準確的,二者的差異就是TIMESTAMP WITH TIME ZONE
關鍵是上述的sql改成下面形式就報錯了
SELECT extract(epoch FROM TIMESTAMP WITH TIME ZONE valid_end_time) , valid_end_time as valid_end_time FROM cms_policy_access WHERE valid_flag = 1 and type = '00101'
各類形式的語法都試了,仍是沒用
繼續百度,終於獲得另一個方法,直接貼sql:
SELECT cast(extract(epoch FROM date_trunc('second', to_timestamp(to_char(valid_start_time, 'YYYY-MM-DD HH24:MI:SS'), 'YYYY-MM-DD HH24:MI:SS')))* 1000 as text) as "starttime" , extract(epoch FROM valid_start_time) * 1000 , valid_start_time as valid_start_time FROM cms_policy_access WHERE valid_flag = 1 and type = '00101'
能夠看到,這裏二者獲取的時間戳確實不同,通過轉換,發現第一列是正確的。。。
其餘相關的能夠百度
----------------------------------------------
時間戳轉換:
update cms_products_base_info set sale_start_date = to_timestamp('2017-02-01 13:22:11', 'YYYY-MM-DD HH24:MI:SS'), sale_END_date = to_timestamp('2017-04-13 16:22:33', 'YYYY-MM-DD HH24:MI:SS') where product_code = 'YLX'