AI 说“今天”，到底是哪一天？
周六早上，你在广州问 AI：“今天美股科技板块怎么样？”
这看起来是个很普通的问题。但此时美国东部可能还是周五晚上。你说的“今天”，可能是想知道刚结束的美股表现，也可能想看周六发生的科技新闻。如果 AI 直接拿一个日期去搜索，再把取回的行情叫作“今天的最新数据”，回答就可能从第一步开始偏了。
一个日期背后，至少有用户的时间、市场的时间和数据自己的时间。它们不一定是同一天，也不能互相代替。
周六问美股，究竟想问什么？
假设广州是周六上午八点，纽约仍是周五晚上。用户的自然日是周六；纽约的自然日是周五。这只是时区换算，不能凭它断言市场一定正常开市，也不能断言某个报价就是最终收盘价。
因为交易所会休市、提前收盘，数据服务也可能延迟。即使某场交易按日历已经结束，拿到的数据仍可能停留在更早的时点。
所以一个靠谱的回答，应尽量让读者看清：问题按哪个时间理解，市场日历确认了什么，引用的数据又截至何时。缺少其中一项时，说“还不知道”比填一个看似精确的日期更有用。
任务跨过午夜，“今天”会变吗？
再想一个场景：你周五晚上让 Agent 研究“今天的新闻”，任务暂停后，周六凌晨恢复。对于同一个尚未完成的任务，“今天”通常应该继续指向你提出问题时的时间，而不是偷偷变成恢复时的周六。
这并不意味着系统不能知道现在已经是周六。它需要同时记住两件事：任务原来何时开始，以及现在又观察到了什么时间。如果用户后来明确要求更新到周六，那是新的要求，应当清楚地体现出来。
这个差别听起来细，却直接影响前后资料能不能放在一起比较。否则一份报告的前半段和后半段，可能在回答两个不同的“今天”。
时区也不能靠猜
有人用中文提问，不代表一定在北京时间；研究美股，也不代表用户希望所有日期都按纽约时间解释。明确指定的时区、用户保存的偏好与设备提供的时区，都有各自的来源。没有可靠依据时，系统应保留未知，必要时问一句，而不是根据语言或市场猜测。
夏令时也提醒我们：纽约并不是永远比 UTC 慢固定的几个小时。合适的做法是使用有规则的地区时区，而不是把某个季节的偏移量写死。
我们的实践还在路上
在 ETF Agent 的时间语义工作中，我们尝试把这些事实分开：由模型理解用户想问的时间，由代码换算已经选定的时间，让市场日历和行情来源分别提供证据。原任务恢复时保留原来的时间锚点；日历不可用时不靠“周一到周五”猜交易日。
截至技术站原文记录的 2026 年 10 月 24 日，相关能力已有部分实现和限定的本地证据，但真实日历接入的完整验证及正式收尾仍未完成。它还不能证明系统已经稳定回答所有“最新交易日”问题。
“最新”不是一个贴上去就成立的标签。让 AI 回答时间敏感的问题，先问清楚：谁的今天、哪个市场的时段、哪份数据截至什么时候？
你在使用 AI 查新闻或行情时，遇到过“日期看似正确，实际不是你想问的那一天”吗？
本文根据 ETF Agent 技术站原文整理。更多工程实践见 GitHub 文章仓库，欢迎交流和 Star。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
AI says, "Today," which day is it?
Saturday morning, you asked AI in Guangzhou, "How's America's Technology Board today?"
It seems to be an ordinary question. But at this point, Eastern America may still be Friday night. What you said, "Today," was that you wanted to know what happened to the U.S. stock at the end of the day, or that you wanted to see what happened on Saturday. If AI takes a date directly to search, then it calls the retriever's "update data for today" and the answer may have been biased from the first step.
Behind a date is at least the time of the user, the time of the market and the time of the data itself. They are not necessarily the same day and cannot replace one another.
Ask the U.S.S.S. Saturday. What do you want to ask?
Assuming Guangzhou is 8 a.m. Saturday, New York is still Friday night. The user's natural day is Saturday; New York's natural day is Friday. This is merely a time zone convert, which cannot be relied upon to assert that the market must be open and that a particular offer is the final offer.
Data services may also be delayed because exchanges are closed and closing early. Even if a transaction is completed by calendar, the data obtained may remain at an earlier point.
So a simple answer should be as clear as possible to the reader: the question is when to understand, what the market calendar confirms, and the data cited up to the date. When one of them is missing, it is more useful to say “not yet known” than to fill out a date that appears to be accurate.
Mission over midnight. Will today change?
Think of another scene: you let Agent study "The News of Today" on Friday night, and resume Saturday morning after the suspension. For the same unfinished task, “day” should normally continue to point to the time when you are asked a question, rather than sneaking into a recovery Saturday.
That does not mean that the system cannot know it's Saturday. It needs to remember two things at the same time: when the mission began and what time it is now observing. If the user subsequently explicitly requests an update until Saturday, that is a new requirement and should be clearly reflected.
This difference sounds fine, but it directly affects whether the information is comparable. Otherwise, the first and second half of a report might answer two different “Today”.
You can't guess the time zone.
Questions had been asked in Chinese, which did not mean that time had to be spent in Beijing; nor did the research unit mean that users wanted all the dates to be explained in New York time. The specified time zones, user-maintained preferences and equipment-provided time zones have their respective sources. Where there is no reliable basis, the system should retain the unknown and ask if necessary, rather than be based on language or market speculation.
We were reminded that New York is not always a fixed number of hours behind UTC. It would be appropriate to use a regular regional time zone rather than write down deviations from a certain season.
Our practice is still on the way.
In the time semantics of ETF Agent, we try to separate these facts: the model understands the time that the user wants to ask, the time that the code convert has chosen, and allows the market calendar and the source to provide evidence separately. Keeps the original time anchor when the original task resumes; when the calendar is not available, it does not rely on “Monday to Friday” to guess the trading date.
As of 24 October 2026, as recorded in the original version of the technology station, local evidence of the partial realization and qualification of the relevant capabilities was available, but the full validation and formal closure of the real calendar access was still incomplete. It could also not prove that the system had stabilized its response to all “late trading days”.
The "newest" is not a label that was created. Let AI answer time-sensitive questions by asking who's today, which market time, which data until?
Did you meet with "the date seems right, it's not the day you want to ask" when you're using AI to check the news or practice?
This post is based on the original version of the ETF Agent technology station. For more engineering practice see GitHub article warehouse, welcome communication and Star.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.