Looks like it's during the hour from 23:00 to 24:00, starting last night, and I'd guess continuing for a week, until let expirableTime = Date.now() - 8 * 24 * 60 * 60 * 1000; goes back to making a time that's more than 7 days in the past even allowing for the daylight saving time change. I pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/a62abefaab90 to mozilla-inbound, a few minutes too late to catch this instance so it won't get a chance to take effect until tomorrow night, but I see by https://tbpl.mozilla.org/php/getParsedLog.php?id=7274961&tree=Mozilla-Aurora and friends that it's already on Aurora, and so will be on Beta tomorrow, so even if that's the right thing to do we'll need a bug and flags to land it there.
Thank you, yes subtracting 8 days is not enough due to the fact expiration uses strftime('%s','now','localtime','start of day','-7 days','utc') that also subtracts today expiration tests do different and that's saving them, not sure why I didn't fix that test the same way :( http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/tests/expiration/head_expiration.js#138
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Comment on attachment 572761 [details] [diff] [review] patch v1.0 Supposing this will land after the Aurora uplift, this should be fixed in Aurora and Beta too. tests-only.
Attachment #572761 - Flags: review?(dietrich) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Comment on attachment 572761 [details] [diff] [review] patch v1.0 [triage comment] Approved for beta and aurora. Please land as soon as possible.
I landed this on aurora: http://hg.mozilla.org/releases/mozilla-aurora/rev/7f1b098d8fc8 But it din't apply cleanly to beta. Please land on beta.
yeah for beta the 9 should be changed to a 8, since Aurora had a workaround philor pushed temporily in central the day before the merge. Will do that.
You need to log in before you can comment on or make changes to this bug.