claude
45a5e37963
A phone posts an RFC 3339 instant ending in Z, and the clock inside the text is a wall clock nobody means in UTC. The wall clock used to be resolved against Posted's own zone, so on this UTC+4 box a 14:30 standup was stored at 18:30. The size of the error is the deploy's offset, which is why the tests never saw it: they ran on a UTC box. EventFromNotificationIn takes the zone explicitly and EventFromNotification passes time.Local. The day comes from Posted's local day too, since a notification posted at 23:30Z saying "завтра" is already tomorrow where he is standing. Posted itself stays an instant, so the past-grace check still compares instants. The two handler fixtures said a bare "10:00" against a 09:40Z post, which is stale once the clock is read locally. They say "завтра" now, so they mean a future meeting in every zone. internal/calendar and cmd/mavweb pass under UTC, Europe/Samara, America/Los_Angeles, Pacific/Kiritimati and Asia/Kathmandu.