the following error has started appearing in the errors logs: "Invalid local time for date in time zone: America/Los_Angeles" cajbir reports he gets this when visiting 'preferences' --> 'account information', however i've been unable to replicate that even after explicitly setting my timezone to LA. it's possible, but unlikely, this is related to the outdated dst data on the webheads (bug 934218).
Summary: "Invalid local time for date in time zone: America/Los_Angeles" when visiting → "Invalid local time for date in time zone: America/Los_Angeles" when visiting 'preferences' --> 'account information'
that error means that the time requested falls within a DST switch, so it isn't a valid time. i can trigger it by creating an object for 2014-03-09.02:01:00 in American/Los_Angeles. as far as i can tell the preferences page doesn't create _any_ datetime objects, and i'm not getting a stack trace from the error.
here's what's happening: our tokens have a maximum lifetime of 3 days. cajbir put in an email change request exactly 3 days before the dst cutover, and has a token with the issue_date of "2014-03-06 02:47:53". when visiting the account preferences page, we show information on pending account change tokens, part of which involves asking mysql for issue_date+max_token_age: > SELECT '2014-03-06 02:47:53' + INTERVAL 3 day > 2014-03-09 02:47:53 that date returned by mysql is wrong - it should be 2014-03-09 03:47:53. 02:47:53 on that day doesn't exist. the crux of this issue is bugzilla doesn't store dates at utc in the database (it should, bug 452353), however that isn't likely to be resolved any time soon.
Assignee: glob → nobody
Depends on: 452353
Whiteboard: [blocker will fix]
You need to log in before you can comment on or make changes to this bug.