TWed2k - 程式開發討論區 - [求助] 請教資料庫的時間紀錄觀念

bbx1
銅驢友〔中級〕

bb

．積分： 132
．精華： 1
．文章： 402
．收花： 822 支
．送花： 528 支
．比例： 0.64
．在線： 1632 小時
．瀏覽： 8344 頁
．註冊： 7452 天
．失蹤： 2373 天

#1 : 2010-5-6 12:19 PM 只看本作者	送花 (0) 送出中...

上次感謝各位的幫忙, 受益良多

小弟也開始嘗試往 PHP/DB 跨出第一步了
以後還請多多....不, 這次就需要麻煩各位多多指教了XD
--------------
這次是想請教各位高手只是個觀念問題
資料庫常常會紀錄到時間
假如今天要做一個網站, 使用者來自各地
當使用者瀏覽網站時, 資料被建立的時間要被轉換為該使用者當地的時間

在這樣的設計前提下, 我該在資料紀錄UTC時間好呢? 還是以Server的Timezone為主即可?
似乎各有利弊?

請大大們就自己的經驗指教一下,
感激不盡!

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆

陽だまり
白銀驢友

ささらの可愛さは異常

．積分： 1330
．精華： 1
．文章： 3159
．收花： 10387 支
．送花： 26639 支
．比例： 2.56
．在線： 4508 小時
．瀏覽： 30308 頁
．註冊： 7436 天
．失蹤： 1444 天
．星の彼方

#2 : 2010-5-10 01:47 AM 只看本作者	送花 (0) 送出中...

用gmt +0的時間做記錄
用戶可以自己選時區
這樣如何呢?

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆

bbx1
銅驢友〔中級〕

bb

．積分： 132
．精華： 1
．文章： 402
．收花： 822 支
．送花： 528 支
．比例： 0.64
．在線： 1632 小時
．瀏覽： 8344 頁
．註冊： 7452 天
．失蹤： 2373 天

#3 : 2010-5-11 10:09 AM 只看本作者	送花 (0) 送出中...

目前我的作法是紀錄UTC, 因為沒有使用者註冊機制
所以改用判斷使用者的 IP 得出 Timezone Location, 再把讀出來的 UTC 轉為使用者當地時間
只是有個小麻煩的地方是: 如果管理員要直接 Database 維護時, 時間就不是當地時間了

相反地, 如果用Server Time做紀錄的話就可以排除掉上述的麻煩
但想了一下好像反而更不妥:
1. query 出來的 Time 要先轉為 UTC, 再轉為當地時間, 頗麻煩 (以效能而言)
2. 如果未來 Server 轉移不知道會不會產生問題 (MySQL 的 Current_Timestamp 屬性?)

感覺兩種作法都有其缺點, 不過因為我會做管理員後台, Admin可以從網頁上控管資料, 所以我才選第一種方式紀錄

陽だまり先輩, gmt 在沒有使用者機制下用做紀錄妥當嗎?
我是考慮還要分析日光節約太麻煩所以改用 Timezone 的XD
指教指教, tnx

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆

陽だまり
白銀驢友

ささらの可愛さは異常

．積分： 1330
．精華： 1
．文章： 3159
．收花： 10387 支
．送花： 26639 支
．比例： 2.56
．在線： 4508 小時
．瀏覽： 30308 頁
．註冊： 7436 天
．失蹤： 1444 天
．星の彼方

#4 : 2010-5-11 09:51 PM 只看本作者	送花 (0) 送出中...

小弟不是前輩

不過用ip來判定的話
whois回來的同樣是us
但時區就有不同的地方不是

所以這應該也是不準

而就算讓使用者可以自己選擇
也不見得所有的使用者都會選擇自己正確的時區這樣

不過小弟不知bbx1兄主要的目的是做什麼
所以也不確定那一種比較好這樣

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆

ma1111
鐵驢友〔高級〕

今日心情

．積分： 69
．文章： 450
．收花： 373 支
．送花： 396 支
．比例： 1.06
．在線： 658 小時
．瀏覽： 13766 頁
．註冊： 7761 天
．失蹤： 733 天

#5 : 2010-5-12 01:38 AM 只看本作者	送花 (0) 送出中...

基本上很簡單,
資料庫重點是統合,時間定義清楚就好,
用gmt +0或主機時間都可以(主機要裝校時軟體)

至於使用者的時區問題,應該在UI層再作轉換

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆

bbx1
銅驢友〔中級〕

bb

．積分： 132
．精華： 1
．文章： 402
．收花： 822 支
．送花： 528 支
．比例： 0.64
．在線： 1632 小時
．瀏覽： 8344 頁
．註冊： 7452 天
．失蹤： 2373 天

#6 : 2010-5-12 02:21 PM 只看本作者	送花 (0) 送出中...

不只有國家吧? timezone應該還有細分區域, 我是知道PHP有:
http://www.php.net/manual/en/timezones.america.php
網路上也滿多人在問 Auto Detecting user's timezone 的方式
還沒很仔細研究過, 不過我想大概沒問題吧?

我想做的網站嘛.... 舉例來說:
一個國際的新聞網站, 在不需要使用者註冊的情況下
新聞快訊的時間會自動轉換為瀏覽者的當地時間

引用:

ma1111寫到:

基本上很簡單,
資料庫重點是統合,時間定義清楚就好,
用gmt +0或主機時間都可以(主機要裝校時軟體)

至於使用者的時區問題,應該在UI層再作轉換

那倒也是, 或許我過於吹毛求疵吧XD
想知道有沒有兩全其美的辦法是自己沒想到的就是了:p

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆

陽だまり
白銀驢友

ささらの可愛さは異常

．積分： 1330
．精華： 1
．文章： 3159
．收花： 10387 支
．送花： 26639 支
．比例： 2.56
．在線： 4508 小時
．瀏覽： 30308 頁
．註冊： 7436 天
．失蹤： 1444 天
．星の彼方

#7 : 2010-5-12 06:08 PM 只看本作者	送花 (0) 送出中...

如果要轉成當地時間來顯示的話
那可以一個欄位記錄gmt+0的時間、第二個欄位記錄+-n的時間這樣
或者要詳細一點資料的話、多二個欄位分別記錄國家、區這樣
使用者只會用到gmt+0的時間、+-n的數字
管理者會多用到國家、區這樣

跑的效能應該是不用擔心
只要資料庫規劃的好，都不會是太大問題

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆

bbx1
銅驢友〔中級〕

bb

．積分： 132
．精華： 1
．文章： 402
．收花： 822 支
．送花： 528 支
．比例： 0.64
．在線： 1632 小時
．瀏覽： 8344 頁
．註冊： 7452 天
．失蹤： 2373 天

#8 : 2010-5-17 09:59 AM 只看本作者	送花 (3) 送出中...

謝謝各位的意見, 目前就以標準時間來做基準試寫下去
到時候如果有其他沒考量到的情況發生再向各位報告
謝謝各位了 :)

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆

桂正和
銀驢友〔初級〕

論壇第一窮

今日心情

．積分： 448
．文章： 777
．收花： 3245 支
．送花： 1392 支
．比例： 0.43
．在線： 1624 小時
．瀏覽： 33426 頁
．註冊： 8020 天
．失蹤： 1462 天
．台灣

#9 : 2010-7-28 02:08 AM 只看本作者	送花 (3) 送出中...

我自己的做法是以伺服器時間為主
但是如果是要考量到全世界的角度來看的話
用GMT+0會比較好

另外儲存時間的格式來說
其實我不愛用時間欄位
反而是用數值欄位
例如
20100728020500這樣

主要是方便比對
而且有時候會因為主機的格式不同或其他問題
導致轉換上會有很多小狀況發生
單純存成數值型態的話
也比較不會有這類問題

輸出到頁面的時候
再利用程式在寫個轉換的小函數去轉換回正規時間格式即可

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆

GERRYccc
名譽版主

凹～～嗚～～^^y

今日心情

．積分： 103
．文章： 597
．收花： 497 支
．送花： 754 支
．比例： 1.52
．在線： 446 小時
．瀏覽： 7391 頁
．註冊： 8212 天
．失蹤： 103 天
． ~@.@~ TWed2k 星球

#10 : 2010-9-8 11:35 PM 只看本作者	送花 (3) 送出中...

我想AP會用到的時間欄位，通常都是跟伺服器時間比較有關，
因此我一定都會存伺服器時間，若需考量全世界的時間共用，
我會讓使用者選擇時區，在撈出時間後再去做加或減時區轉換。

而資料庫欄位的型態上，我偏好使用14碼字串(String): 20100908233552
要使用時一樣再用函式去做轉換成適合使用者看的格式，

好處是顯示方便、轉換方便、比對方便、比較大小也方便!!

上述供您參考.

[GERRYccc 在 2010-9-8 11:36 PM 作了最後編輯]

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆