PTT數位生活區 / PHP

Re: [請益] 04跟4會不會有差?

看板PHP作者 (肯先生)時間15年前 (2010/09/26 19:37), 編輯推噓2(2推 0噓 20→)
留言22則, 4人參與, 最新討論串2/3 (看更多)
※ 引述《ntuguy (ya)》之銘言： : 各位大大 : 有個小問題請教 : 因為我現在在經營一個網站 : 希望他們註冊的生日格式為0000/00/00 : 請問像1995/04/01 : 跟1995/4/1 : 這在未來系統讀取資料上 : 會不會有差別 : 如果有的話 : 我可能要統一規定為1995/04/1的格式比較妥吧! : 謝謝!! 感覺上要轉 database 板回答..如果使用的是 mysql 的話： http://dev.mysql.com/doc/refman/5.1/en/datetime.html 10.3.1. The DATETIME, DATE, and TIMESTAMP Types 有特別說明：「The DATETIME, DATE, and TIMESTAMP types are related. This section describes their characteristics, how they are similar, and how they differ. 」 裡面特別舉了一個例子：'1979-6-9' is the same as '1979-06-09'。 個人感覺是，統一格式是比較好的，substr($d,5,2) 一定比 date('m',strtotime($d)) 還要快。 再者，你存入資料庫的資料，一定要有習慣經過「整理」後才放進去。 例如是 datetime 的欄位，就一定要先 $d = date("Y-m-d H:i:s",strtotime($d));， 同理，int 的欄位，就要先 $i = (int) $i; 再存進去。 10.3.1.1. TIMESTAMP Properties 裡面有提到：「TIMESTAMP values are converted from the current time zone to UTC for storage, and converted back from UTC to the current time zone for retrieval. (This occurs only for the TIMESTAMP data type, not for other types such as DATETIME.)」 個人感覺是，用 datetime 比較直覺。 主要在維護的時候，一眼就可以看出來時間，不過也可以兩個欄位一起使用，反正也佔 不了多少儲存空間。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.166.140.84 ※ 編輯: KC73 來自: 118.166.140.84 (09/26 19:38)
→
09/26 23:00, , 1F
存成unix time只要int 4byte而以ㄟXD
09/26 23:00, 1F
→
09/27 02:53, , 2F
一個 datetime 19 個 bytes，大概 6 到 10 個中文字。
09/27 02:53, 2F
推
09/28 02:11, , 3F
UNIXTIMESTAMP 可能會遇到西元 2038 的問題...
09/28 02:11, 3F
→
09/28 02:13, , 4F
不確定軟體會在何種平台運作的話，MySQL 的 DATETIME 較好
09/28 02:13, 4F
→
09/28 06:05, , 5F
2038年，那是php的int的最大值問題吧，2038年都不知道多久
09/28 06:05, 5F
→
09/28 06:06, , 6F
之後的事，一套系統不可能用那麼久而不更新吧
09/28 06:06, 6F
→
09/28 07:15, , 7F
http://tinyurl.com/3xftv9n 64bits的平台,PHP的timestamp可
09/28 07:15, 7F
→
09/28 07:16, , 8F
以記錄到 292,277,026,596年12月4日15:30:08
09/28 07:16, 8F
→
09/28 07:18, , 9F
2038年的問題,不見得要到2038年才會遇到,例如有客戶買了30年
09/28 07:18, 9F
→
09/28 07:19, , 10F
的保險.所以 $expire = strtotime("+30 years");
09/28 07:19, 10F
→
09/28 07:20, , 11F
然後存到 mysql 裡面,結果說不定保險公司明天就開始寄期滿的
09/28 07:20, 11F
→
09/28 07:20, , 12F
保險金給這個客戶.
09/28 07:20, 12F
推
09/28 19:14, , 13F
如果 PHP 軟體是要拿去賣得，你要限制客戶用 64bit ？
09/28 19:14, 13F
→
09/28 19:14, , 14F
還是自己處理掉 32bit 與 64bit OS 造成的差異？
09/28 19:14, 14F
→
09/28 19:16, , 15F
KC73 大說對了，真的 28 年後才會遇到？
09/28 19:16, 15F
→
09/28 19:16, , 16F
人無遠慮，必有近憂啊....
09/28 19:16, 16F
→
09/28 20:36, , 17F
聽說以後會改用float紀錄是吧，如果沒有這種「保單」的
09/28 20:36, 17F
→
09/28 20:36, , 18F
問題，應該可以考慮用吧@@?
09/28 20:36, 18F
→
09/29 08:35, , 19F
float 有時候會有「誤差」，可以看一下 manual 的說明。
09/29 08:35, 19F
→
10/02 01:15, , 21F
更正，datetime 是 8 bytes 就好。
10/02 01:15, 21F
→
10/02 01:16, , 22F
10/02 01:16, 22F
‣ 更多 KC73 的文章
文章代碼(AID): #1Cdp1wEq (PHP)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 2 之 3 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共3篇)
PHP 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 KC73 的文章
文章代碼(AID): #1Cdp1wEq (PHP)