我为使用ORDER BY
过滤器的事件日历查询设置了自定义posts_where
子句。它看起来像这样:
// $compareTimeToday is the result of strtotime('today');
// $compareTimeTomorrow is the result of strtotime('tomorrow');
// MIN(wp_postmeta.meta_value) ultimately fetches the _EventStartDate
// post meta, which is in MySQL format (YYYY-MM-DD H:i:s)
// This query forces events happening today ahead of events that are
// happening today but are multi-day and started in the past
$orderby = "CASE
WHEN MIN(wp_postmeta.meta_value) BETWEEN FROM_UNIXTIME($compareTimeToday) AND FROM_UNIXTIME($compareTimeTomorrow)
THEN 1
ELSE 2
END ASC, " . $orderby;
事情似乎很好,但是客户添加了一些事件,确实设法弄乱了这个。在客户端添加了这些事件之后,我提取了数据库的副本,因此我的本地数据库完全匹配暂存。
在我的本地环境中,结果如下:
所以今天开始的事件,然后是日期顺序的所有其他即将发生的事件(在这种情况下从8月开始的事件开始)。 在该列表的底部是一个昨天开始并持续到11月的多日活动,这是该网站上的最后一个活动。您将在下一个屏幕截图中看到它。
以下是暂存环境显示的内容:
列表底部的项目现在位于顶部(不需要)。
为什么我在完全相同的代码集和数据库上的两台机器之间得到不同的结果?
本地PHP:7.1.0 本地MySQL:5.7.16
暂存PHP:7.0.2 暂存MySQL:5.7.18
如果我将date_default_timezone_get()
转储给他们,他们都会显示“UTC”。
知道为什么我在两者之间得到不同的结果吗?
编辑:客户端的服务器管理团队告诉我,虽然PHP吐出了UTC,但是登台服务器本身可能在东部时间。如果进入查询的PHP变量和数据库的内容在两个环境之间都是相同的,这有关系吗?
答案 0 :(得分:0)
感谢@Shadow的正确方向。 MySQL时区确实America\New York
似乎正在FROM_UNIXTIME
上运行一些转换,而dev是普通的UTC
这是更复杂的,因为WordPress允许您在管理员中设置时区,但不会强制在PHP级别,并进一步操作假定UTC,所以你必须设置然后重置时区管理员设置很重要。