你在centos上執(zhí)行下命令date，看是什么時間，是不是北京時間，不是就改下就好了。mysql應(yīng)該默認取的系統(tǒng)時間
為新野等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及新野網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站制作、做網(wǎng)站、新野網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！
目前你遇到的問題大概是 PHP 獲取的時間和 MySQL中獲取的時間存在時差
比較直接的解決方案是在 PHP 和 MySQL 中遵循同一時區(qū)約定
PHP 在5.0 之后應(yīng)該可以直接在代碼中設(shè)定時區(qū)
date_default_timezone_set('PRC');
MySQL 也可以通過修改配置文件 my.ini 或者 my點吸煙 f 確保時區(qū)正確
default-time-zone=timezone
問題是你的MySQL服務(wù)器可能是在某臺美國服務(wù)器上租借的，沒法修改
所以解決的方法只能是：
修改插件源代碼，將 SQL 語句改為
select forum_id, count(post_id) todayposts
from ' .POSTS_TABLE. '
where date(from_unixtime(post_time)) = date(DATE_ADD(now(), INTERVAL 14 HOUR))
group by forum_id
其中的 DATE_ADD(now(), INTERVAL 14 HOUR) 是-14 還是 14，這需要你仔細考慮下
你還在被以下問題困擾嗎：
MySQL的安裝規(guī)范中應(yīng)該設(shè)置什么時區(qū)？
JAVA應(yīng)用讀取到的時間和北京時間差了14個小時，為什么？怎么解決？
已經(jīng)運行一段時間的業(yè)務(wù)，修改MySQL的時區(qū)會影響已經(jīng)存儲的時間類型數(shù)據(jù)嗎？
遷移數(shù)據(jù)時會有導(dǎo)致時間類型數(shù)據(jù)時區(qū)錯誤的可能嗎？
...
看完這篇文章，你能解決上面所有的疑惑。首先出場的是和時區(qū)相關(guān)的啟動參數(shù)和系統(tǒng)變量。
如果要在 MySQL 啟動時就指定時區(qū)，則應(yīng)該使用啟動參數(shù)： default-time-zone ，示例：
啟動后我們可以看到控制時區(qū)的系統(tǒng)變量，其中 time_zone 變量控制時區(qū)，在MySQL運行時可以通過 set 命令修改（注意：不可以寫在 my點吸煙 f 中）：
啟動參數(shù)和系統(tǒng)變量的可用值遵循相同的格式：
system_time_zone 變量只有全局值沒有會話值，不能動態(tài)修改，MySQL 啟動時，將嘗試自動確定服務(wù)器的時區(qū)，并使用它來設(shè)置 system_time_zone 系統(tǒng)變量， 此后該值不變。當 time_zone='system' 時，就是使用的這個時區(qū)，示例中 time_zone 就是 CST，而 CST 在 RedHat 上就是東八區(qū)：
概括一下就兩點：
不僅是select now()，包括insert .. values(now())、以及字段的 DEFAULT CURRENT_TIMESTAMP 屬性也受此影響：
timestamp 數(shù)據(jù)類型會存儲當時session的時區(qū)信息，讀取時會根據(jù)當前 session 的時區(qū)進行轉(zhuǎn)換；而 datetime 數(shù)據(jù)類型插入的是什么值，再讀取就是什么值，不受時區(qū)影響。也可以理解為已經(jīng)存儲的數(shù)據(jù)是不會變的，只是 timestamp 類型數(shù)據(jù)在讀取時會根據(jù)時區(qū)轉(zhuǎn)換：
關(guān)于時區(qū)所有明面上的東西都在上面了，我們前面提到的困擾就是在暗處的經(jīng)驗。
1. MySQL的安裝規(guī)范中應(yīng)該設(shè)置什么時區(qū)？
對于國內(nèi)的業(yè)務(wù)了，在 my點吸煙 f 寫入 default-time-zone='+08:00' ，其他地區(qū)和開發(fā)確認取對應(yīng)時區(qū)即可。
為什么不設(shè)置為 system 呢？使用系統(tǒng)時間看起來也是個不錯的選擇，比較省事。不建議的原因有兩點：
2. JAVA應(yīng)用讀取到的時間和北京時間差了14個小時，為什么？怎么解決？
這通常是 JDBC 參數(shù)中沒有為連接設(shè)置時區(qū)屬性（用 serverTimezone 參數(shù)指定），并且MySQL中沒有設(shè)置全局時區(qū)，這樣MySQL默認使用的是系統(tǒng)時區(qū)，即 CST。這樣一來應(yīng)用與MySQL 建立的連接的 session time_zone 為 CST ，前面我們提到 CST 在 RedHat 上是 +08:00 時區(qū)，但其實它一共能代表4個時區(qū)：
JDBC在解析CST時使用了美國標準時間，這就會導(dǎo)致時區(qū)錯誤。要解決也簡單：一是遵守上面剛說到的規(guī)范，對MySQL顯式地設(shè)置'+08:00'時區(qū)；二是JDBC設(shè)置正確的 serverTimezone。
3. 已經(jīng)運行一段時間的業(yè)務(wù)，修改MySQL的時區(qū)會影響已經(jīng)存儲的時間類型數(shù)據(jù)嗎？
完全不會，只會影響對 timestamp 數(shù)據(jù)類型的讀取。這里不得不提一句，為啥要用 timestamp？用 datetime 不香嗎，范圍更大，存儲空間其實差別很小，趕緊加到開發(fā)規(guī)范中吧。
4. 遷移數(shù)據(jù)時會有導(dǎo)致時間類型數(shù)據(jù)時區(qū)錯誤的可能嗎？
這個還真有。
如何避免？mysqldump 也提供了一個參數(shù) --skip-tz-utc ，意思就是導(dǎo)出數(shù)據(jù)的那個連接不設(shè)置 UTC 時區(qū)，使用 MySQL 的 global time_zone 系統(tǒng)變量值。
其實 mysqldump 導(dǎo)出 sql 文件時默認也是使用 UTC 時區(qū)，并且會在導(dǎo)出的 sql 文件頭部帶有 session time_zone 信息，這樣可以保證導(dǎo) SQL 文件導(dǎo)入和導(dǎo)出時使用相同的時區(qū)，從而保證數(shù)據(jù)的時區(qū)正確（而導(dǎo)出的 csv 文件顯然不可以攜帶此信息）。需要注意的是 --compact 參數(shù)會去掉 sql 文件的所有頭信息，所以一定要記得： --compact 參數(shù)得和 --skip-tz-utc 一起使用。
MySQL JDBC 8.0.25版本中的時區(qū)處理與之前的版本有所差異。具體來說，這些差異主要涉及以下方面：
1. 時區(qū)轉(zhuǎn)換：MySQL JDBC 8.0.25版本默認使用UTC時區(qū)進行時間戳的轉(zhuǎn)換。如果需要在應(yīng)用程序中使用本地時區(qū)或其他時區(qū)，需要通過設(shè)置連接參數(shù)或使用JDBC API進行相應(yīng)的設(shè)置。
2. 日期時間類型的處理：MySQL JDBC 8.0.25版本中，日期時間類型的值會被轉(zhuǎn)換為Java8中的日期時間類型（例如java.time.LocalDateTime、java.time.ZonedDateTime等）。這些類型與之前版本中的java.sql.Date和java.sql.Timestamp有所不同，需要注意使用方式和轉(zhuǎn)換規(guī)則。
3. 時區(qū)信息的獲取：MySQL JDBC 8.0.25版本中，可以通過使用JDBC API獲取MySQL服務(wù)器的時區(qū)信息，以便在應(yīng)用程序中進行時區(qū)轉(zhuǎn)換和處理。
需要注意的是，這些差異可能會對已有的應(yīng)用程序產(chǎn)生影響，需要對應(yīng)用程序進行相應(yīng)的修改和適配。同時，在使用MySQL JDBC 8.0.25版本時，需要仔細閱讀官方文檔，了解其提供的新特性和變化，以便更好地使用和管理MySQL數(shù)據(jù)庫。
