我有一个HistogramLutItem字段，我正在尝试使用datetime来查看CONVERT_TZ个日期。这是一个选择的例子：
BETWEEN这样可以正常工作并返回结果。但是，当我尝试在应该返回结果的SELECT (DATE_FORMAT(CONVERT_TZ(`created_at`,'+00:00','+05:00'), ' %Y-%m-%d')) FROM `pages`
子句中使用它时：
WHERE这不会返回任何内容。但是那些日期之间，有许多记录应该在那些之间进行验证。
答案 0 :(得分：0)
我现在手头没有MySQL。话虽如此，我只是想提供一些快速提示：
1）DATE_FORMAT returns a string，您正在比较<style>
.thread {
background-color: skyblue;
height: 50px;
width: 90%;
align-self: center;
text-align: end;
display: inline-block;
border-radius: 6px;
position: relative;
}
.header {
width: fit-content;
display: inline-block;
align-self: right;
}
.arrow {
display: inline-block;
vertical-align: bottom;
height: 50%;
}
.titletext {
display: inline-block;
float:left;
}
</style>
<div class="thread">
<p class="titletext">Title</p>
<div class="header"><img class="arrow" onclick="showPopover(this)" src="https://image.flaticon.com/icons/png/512/7/7584.png" /></div>
</div>
子句中的字符串。从您的声誉来看，我绝对相信您知道在某些情况下将数字（或其他数字类型）作为字符串进行比较并不是最明智的事情： - ）。
2）如果你想比较考虑时区的日期时间，你最终应该使用指定时区的常数（在你的情况下，硬编码的下端和上限的间隔）问题）。至少，对于其他人而言，这将是一致且易于理解的。
3）请注意TIMESTAMP field in MySQL converts data being inserted to UTC, taking the current time zone into account, and does the opposite process with data being read, while a DATETIME field does not do that（您没有提及所涉及领域的类型）。这可能会导致WHERE字段出现意外结果。
出于这个原因，我从未使用TIMESTAMP字段（我正在进行时区转换，通常与后端代码或客户端代码中的区域设置转换相关联，至少在数据库之外）软件）。因此，如果您比较TIMESTAMP字段，我就不知道MySQL的行为方式。它首先将值从字段中拉出，从而将其从UTC转换为当前时区，然后进行比较，还是根据存储在字段中的原始（UTC）数据执行比较？
作为最后一点，您的TIMESTAMP声明当然也会将日期时间作为字符串返回，但在这种情况下，您不会注意到，因为您只是查看它们，但没有进行计算（或比较）与他们。