Does anyone actually test what their vibe-coded app does when the user’s clock or timezone is wrong?
Found this by accident last week. A friend opened something I’d built, and the “today” view showed yesterday’s data. His phone was set to a different timezone because he’d been traveling. Nothing crashed, no errors anywhere, it just quietly showed the wrong thing, and he assumed the app was broken...
When I went back through the code, the AI had used the browser’s local time in some places and server time in others, with no consistent rule. Dates were stored as plain strings in one table and timestamps in another. Everything worked perfectly on my machine because my laptop and my server happened to agree...
It’s one of those things nobody puts in a prompt. You ask for “a daily summary” and you get one that works in exactly one timezone. Daylight saving shifts, users who travel, midnight edge cases, a device with a wrong clock: all of it fails silently, and you only hear about it as “your app feels off.”
My current habit is to tell the AI upfront: store everything in UTC, convert only at display time, and then I test once with my system timezone set somewhere far away like Auckland. It takes ten minutes and has already caught two bugs...
Is this on anyone else’s checklist, or does it only come up when a user in another country complains ???
Replies
Yes, because a user hit it. An iPhone whose time zone said UTC minus 7 while the clock showed Spanish local time, so its UTC ran nine hours ahead. Google sign in finished, then the sign in library on the phone checked the fresh token against the phone's clock and called it expired, before my backend was ever reached. Now that error tells the user to set date and time automatically, and the emailed sign in link still works on such a phone because the server checks it. Two other rules I keep for anything with days in it: a holiday gift window is checked on the server in UTC with a day of slack on each side, so every timezone gets its full local day, and the daily bonus holds on to the user's offset and needs 12 hours between claims, so changing the phone's zone can't buy a second day.