你在centos上执行下命令date，看是什么时间，是不是北京时间，不是就改下就好了。mysql应该默认取的系统时间
为新野等地区用户提供了全套网页设计制作服务，及新野网站建设行业解决方案。主营业务为成都网站制作、做网站、新野网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
目前你遇到的问题大概是 PHP 获取的时间和 MySQL中获取的时间存在时差
比较直接的解决方案是在 PHP 和 MySQL 中遵循同一时区约定
PHP 在5.0 之后应该可以直接在代码中设定时区
date_default_timezone_set('PRC');
MySQL 也可以通过修改配置文件 my.ini 或者 my点吸烟 f 确保时区正确
default-time-zone=timezone
问题是你的MySQL服务器可能是在某台美国服务器上租借的，没法修改
所以解决的方法只能是：
修改插件源代码，将 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的安装规范中应该设置什么时区？
JAVA应用读取到的时间和北京时间差了14个小时，为什么？怎么解决？
已经运行一段时间的业务，修改MySQL的时区会影响已经存储的时间类型数据吗？
迁移数据时会有导致时间类型数据时区错误的可能吗？
...
看完这篇文章，你能解决上面所有的疑惑。首先出场的是和时区相关的启动参数和系统变量。
如果要在 MySQL 启动时就指定时区，则应该使用启动参数： default-time-zone ，示例：
启动后我们可以看到控制时区的系统变量，其中 time_zone 变量控制时区，在MySQL运行时可以通过 set 命令修改（注意：不可以写在 my点吸烟 f 中）：
启动参数和系统变量的可用值遵循相同的格式：
system_time_zone 变量只有全局值没有会话值，不能动态修改，MySQL 启动时，将尝试自动确定服务器的时区，并使用它来设置 system_time_zone 系统变量， 此后该值不变。当 time_zone='system' 时，就是使用的这个时区，示例中 time_zone 就是 CST，而 CST 在 RedHat 上就是东八区：
概括一下就两点：
不仅是select now()，包括insert .. values(now())、以及字段的 DEFAULT CURRENT_TIMESTAMP 属性也受此影响：
timestamp 数据类型会存储当时session的时区信息，读取时会根据当前 session 的时区进行转换；而 datetime 数据类型插入的是什么值，再读取就是什么值，不受时区影响。也可以理解为已经存储的数据是不会变的，只是 timestamp 类型数据在读取时会根据时区转换：
关于时区所有明面上的东西都在上面了，我们前面提到的困扰就是在暗处的经验。
1. MySQL的安装规范中应该设置什么时区？
对于国内的业务了，在 my点吸烟 f 写入 default-time-zone='+08:00' ，其他地区和开发确认取对应时区即可。
为什么不设置为 system 呢？使用系统时间看起来也是个不错的选择，比较省事。不建议的原因有两点：
2. JAVA应用读取到的时间和北京时间差了14个小时，为什么？怎么解决？
这通常是 JDBC 参数中没有为连接设置时区属性（用 serverTimezone 参数指定），并且MySQL中没有设置全局时区，这样MySQL默认使用的是系统时区，即 CST。这样一来应用与MySQL 建立的连接的 session time_zone 为 CST ，前面我们提到 CST 在 RedHat 上是 +08:00 时区，但其实它一共能代表4个时区：
JDBC在解析CST时使用了美国标准时间，这就会导致时区错误。要解决也简单：一是遵守上面刚说到的规范，对MySQL显式地设置'+08:00'时区；二是JDBC设置正确的 serverTimezone。
3. 已经运行一段时间的业务，修改MySQL的时区会影响已经存储的时间类型数据吗？
完全不会，只会影响对 timestamp 数据类型的读取。这里不得不提一句，为啥要用 timestamp？用 datetime 不香吗，范围更大，存储空间其实差别很小，赶紧加到开发规范中吧。
4. 迁移数据时会有导致时间类型数据时区错误的可能吗？
这个还真有。
如何避免？mysqldump 也提供了一个参数 --skip-tz-utc ，意思就是导出数据的那个连接不设置 UTC 时区，使用 MySQL 的 global time_zone 系统变量值。
其实 mysqldump 导出 sql 文件时默认也是使用 UTC 时区，并且会在导出的 sql 文件头部带有 session time_zone 信息，这样可以保证导 SQL 文件导入和导出时使用相同的时区，从而保证数据的时区正确（而导出的 csv 文件显然不可以携带此信息）。需要注意的是 --compact 参数会去掉 sql 文件的所有头信息，所以一定要记得： --compact 参数得和 --skip-tz-utc 一起使用。
MySQL JDBC 8.0.25版本中的时区处理与之前的版本有所差异。具体来说，这些差异主要涉及以下方面：
1. 时区转换：MySQL JDBC 8.0.25版本默认使用UTC时区进行时间戳的转换。如果需要在应用程序中使用本地时区或其他时区，需要通过设置连接参数或使用JDBC API进行相应的设置。
2. 日期时间类型的处理：MySQL JDBC 8.0.25版本中，日期时间类型的值会被转换为Java8中的日期时间类型（例如java.time.LocalDateTime、java.time.ZonedDateTime等）。这些类型与之前版本中的java.sql.Date和java.sql.Timestamp有所不同，需要注意使用方式和转换规则。
3. 时区信息的获取：MySQL JDBC 8.0.25版本中，可以通过使用JDBC API获取MySQL服务器的时区信息，以便在应用程序中进行时区转换和处理。
需要注意的是，这些差异可能会对已有的应用程序产生影响，需要对应用程序进行相应的修改和适配。同时，在使用MySQL JDBC 8.0.25版本时，需要仔细阅读官方文档，了解其提供的新特性和变化，以便更好地使用和管理MySQL数据库。