WEEKOFYEAR(NOW())与WEEK('2018-05-1')结果不一致的技术疑问

这个问题的核心差异大概率来自两个关键因素：WEEKOFYEAR的默认规则和时区/日期解析的不一致，下面详细拆解：

1. WEEKOFYEAR与WEEK函数的规则差异 #

在MySQL里，WEEKOFYEAR(date)其实是WEEK(date, 3)的别名，它严格遵循ISO 8601周标准：

• 一周的第一天是周一
• 一年的第一周必须包含当年至少4天（简单说，就是当年第一个包含周四的周才算第1周）

而WEEK(date)如果不指定第二个模式参数，会用MySQL系统变量default_week_format的默认值（通常是0或1，取决于服务器配置），规则和ISO标准不同。不过你提到尝试了模式0到7结果都是17，这说明这个点可能不是主因，那就要看第二个核心因素：

2. 时区导致的日期实际值偏移 #

NOW()返回的是当前服务器时区下的完整日期时间，而你直接传入的字符串'2018-05-1'会被MySQL按照当前会话的时区解析为日期。如果服务器时区和会话时区不一致，就会出现日期“隐形偏移”：

举个典型例子：

• 假设你的服务器时区是UTC+8（东八区），当地时间2018-05-01 00:00:00执行NOW()，得到的是2018-05-01 00:00:00
• 但如果你的会话时区是UTC，字符串'2018-05-1'会被解析为UTC时间的2018-05-01，对应的东八区时间是2018-05-01 08:00:00；反过来，如果服务器时区是UTC，你在东八区的2018-05-01执行NOW()，得到的UTC时间其实是2018-04-30 16:00:00——这时候WEEKOFYEAR(NOW())计算的是4月30日的周数，而你误以为是5月1日的结果。

结合你的情况，更可能是：服务器时区是东八区，NOW()返回的是东八区的5月1日（属于第18周），但你传入的'2018-05-1'被会话时区解析为UTC的5月1日，对应东八区的4月30日（属于第17周），所以两者结果不同。

3. 验证方法 #

你可以通过以下SQL语句排查问题：

-- 查看服务器和当前会话的时区设置
SELECT @@global.time_zone, @@session.time_zone;

-- 对比NOW()和字符串日期的UTC转换结果
SELECT NOW(), CONVERT_TZ(NOW(), @@session.time_zone, 'UTC');
SELECT STR_TO_DATE('2018-05-1', '%Y-%m-%d'), CONVERT_TZ(STR_TO_DATE('2018-05-1', '%Y-%m-%d'), @@session.time_zone, 'UTC');

-- 强制统一时区测试
SET time_zone = '+08:00';
SELECT WEEKOFYEAR('2018-05-01'), WEEK('2018-05-01',3);

正常情况下，当使用模式3时，WEEK('2018-05-01',3)应该返回18，和WEEKOFYEAR结果一致。如果你的测试结果还是17，可能是MySQL版本过旧（比如5.1之前的版本对周函数的实现有差异），或者输入的日期字符串存在隐性错误（比如误写为'2018-04-1'）。

内容的提问来源于stack exchange，提问作者chu8