海外GEO工具把时区硬编码成UTC，我按本地时间跑批白扔了三天预算

上周帮伦敦组跑一批GEO问句，顺手把纽约那套采样配置拷过去。结果出来的引用率比纽约高了快一倍，我第一反应是欧洲用户爱用长问句，差点就写进结论了。

后来随手翻了下服务器日志，发现采样时间戳全是UTC。纽约那边配置里写了America/New_York，伦敦这套我偷懒没改，默认拿UTC跑。问题在于：工具判断"这条问句算不算当天的有效样本"，是按本地营业时间来切的——UTC的0点到8点，正好把伦敦的凌晨批量给算进了前一天。分母直接多吞了一个批次。

我把同一批问句按三个时区各跑了一遍，拿到的有效样本数差得很离谱：

差了700多条样本，引用率虚高12个点。这12个点如果拿去给客户做月报，够我解释一整个下午。

我的判断是：海外GEO工具默认按UTC切批，是因为它的后台是按UTC存的，但它的"营业日"逻辑其实应该跟投放市场的本地时区走。这两个东西在工具里是分开的，配置表里不显眼，很多人第一次跑就栽在这。

我现在固定做三件事：

1. 拿到一个新市场，先把工具后台的时区配置字段扒出来，确认它切批是按哪个时区。
2. 跑批前用date -u和date各打一次服务器时间，跟配置表对一遍。差一个时区就是几百条样本的账。
3. 报告里所有跟"日""周"相关的分母，都单独标一行"切批时区"，别让下游拿去二次计算。

国内现在很多团队接海外GEO的单子，采样时区这个坑我觉得比盐版本号还隐蔽——盐版本号错了至少跑批会报错，时区错了它安安静静给你出一份看着很漂亮的报告。

问一句：你们跑跨时区批次的时候，分母是按UTC切还是按本地营业时间切？有没有人做过同一批问句两个时区对跑、把误差量化的？我想看看别人的数是不是也在这个量级。