面试题库

30 天从前端工程师到 Agent 工程师

D20 定时 Job 与主动关怀：时区、quiet hours、每日上限、通知 provider 抽象

• 做一个面向全球用户的定时推送服务，时区上你会踩到哪些坑？夏令时切换那天怎么处理？Building a scheduled push service for users worldwide, what timezone pitfalls would you hit, and how do you handle the DST switchover day?

  国内高频海外高频深入#timezone#scheduling#correctness

  分析过程 · 先想清楚再作答

  1. 这题的区分度全在夏令时那半句。只答「存 UTC、展示转本地」是及格线，能不能给出夏令时那天的**可验证裁定**决定了你是「知道有坑」还是「填过坑」。
  2. 先把基础两条说死：时间一律存 UTC（存的是绝对时刻），判断前先转成用户本地时区（判断的是墙上时间）。判据是一句可自查的话——只靠这一列加上用户档案里的时区，能不能唯一还原出那个绝对时刻。存本地时间字符串答不上来。
  3. 第二个坑是时区字段本身：必须存 IANA 标识（Asia/Shanghai）而不是 UTC 偏移量。偏移量一年会随夏令时变两次，标识是规则、偏移量只是规则在某一天算出来的结果，存结果的那一刻它就过期了。
  4. 第三个坑是夏令时那天的两种反常：春季前跳会让某个本地时间**根本不存在**（纽约 2026-03-08 的 02:30），秋季回拨会让某个本地时间**出现两次**（2026-11-01 的 01:30）。只要你的调度点落在这两个窗口里，「每天早上 8 点发」就解释不出唯一答案。裁定要显式给出而不是交给库随便选：不存在就顺延到过渡之后（02:30 变 03:30），出现两次就取第一次——这也正是 java.time 的 ZonedDateTime.of 的默认行为，可以直接写成断言测试。
  5. 第四个坑最容易被漏：用户跨时区旅行时，他的时区以哪一次为准。答案是以用户档案里那个显式字段为准、绝不跟着设备静默漂移；设备上报只用来询问是否切换。更细一层可以补：时区在 24 小时内跳变超过 3 小时时，当天的安静时段按新旧两个时区的并集处理，任何一边在安静就不发——保守的代价是晚几小时收到，激进的代价是在人家凌晨三点响一声。
  6. 可以预期的追问：这种 bug 为什么很难被测出来？因为本机、CI、生产常常都在同一个时区甚至都在 UTC，「忘了转时区」在所有测试里都是绿的。给出判据：把测试用户的时区故意设成三个互不相同、且都不等于服务器时区的值，任何依赖服务器时区的判断当场变红。

  How to reason about it · think before answering

  1. All the signal in this question lives in the DST half. Store UTC, render local is the passing grade; giving a verifiable ruling for the switchover day is what separates knowing the pitfall from having fixed it.
  2. Nail the two basics first: always store UTC (an absolute instant) and convert to the user's zone before any judgement (a wall-clock time). The self-check is one sentence — can this column plus the user's stored timezone uniquely reconstruct the absolute instant? A local time string cannot.
  3. The second pitfall is the timezone field itself: store the IANA identifier (Asia/Shanghai), never a UTC offset. Offsets shift twice a year under DST; the identifier is the rule and the offset is only what that rule evaluated to on one particular day, so it is stale the moment you persist it.
  4. The third is the two anomalies on switchover day: spring-forward makes some local time simply not exist (02:30 on 2026-03-08 in New York), and fall-back makes some local time occur twice (01:30 on 2026-11-01). If your schedule point lands in either window, send at 8am local has no unique answer. State the ruling explicitly rather than leaving it to whatever the library picks: shift a nonexistent time forward past the transition (02:30 becomes 03:30), and take the first occurrence when it happens twice — which is exactly what java.time's ZonedDateTime.of does, so you can assert on it in tests.
  5. The fourth is the one people miss: when a user travels across zones, which timezone counts. Answer: the explicit field on the user profile, never silent drift from device reports; a device report should only prompt the user to confirm a change. Go one level deeper if you can — when the zone jumps more than three hours within 24 hours, treat that day's quiet hours as the union of the old and new zones and stay silent if either is quiet. Being conservative costs a few hours of delay; being aggressive costs a 3am buzz.
  6. Expect: why are these bugs so hard to catch? Because your laptop, CI and production are often all in one zone, frequently UTC, so forgot to convert stays green everywhere. Give the fix: pin the test users to three distinct zones, none equal to the server's, and every server-timezone dependency turns red immediately.

  答题要点

  • 存储一律 UTC，判断前转用户本地时区；自查判据是这一列加时区能否唯一还原绝对时刻
  • 时区存 IANA 标识而不是 UTC 偏移量——偏移量随夏令时一年变两次，存下来就过期
  • 夏令时两种反常：本地时间不存在（春季前跳）、本地时间出现两次（秋季回拨）
  • 裁定要显式且可断言：不存在就顺延到过渡之后，出现两次取第一次（与 java.time 默认一致）
  • 跨时区旅行以用户档案里的显式字段为准，不跟设备漂；跳变超过 3 小时时按新旧时区的并集判安静
  • 测试里把用户时区设成三个不同于服务器的值，否则「忘了转时区」在所有测试里都是绿的

  Key points

  • Store UTC everywhere, convert to the user's zone before judging; the check is whether column plus zone reconstructs the instant
  • Persist IANA identifiers, not UTC offsets — offsets change twice a year and are stale on write
  • Two DST anomalies: a local time that does not exist (spring forward) and one that occurs twice (fall back)
  • Make the ruling explicit and assertable: shift nonexistent times past the transition, take the first of a duplicated pair (matching java.time)
  • For travellers, trust the explicit profile field, not device drift; on jumps over three hours, treat quiet hours as the union of both zones
  • Pin test users to three zones different from the server's, or the missing conversion stays green in every test