WICG
Warn or fail for non-zero expire dates in the distant past
Consider this example:
try {
await cookieStore.set({
name: 'session_id',
value: 'this data will be LOST',
expires: 365 * 24 * 60 * 60 * 1000 });
} catch (e) {
console.error(`Failed to set cookie: ${e}`);
}
Superficially, it looks like this cookie will last for a year, but in fact, 31536000000 is midnight of 1971 UTC. It will silently delete the cookie data the instant you set it, resulting in data loss.
I suggest that the API should warn (or maybe even throw) if the user provides an expires date that's greater than 0 but less than a very large number, like 1514764800000 (1/1/2018 UTC) or something.
In 2020, there is no sane reason to set a cookie to expire in 1971. Anyone who writes expires: 30 or expires: 1000 is incurring a data-loss bug with this API; the API should help developers by at least warning them when they inevitably make this mistake.
(Maybe you think "nobody would make that mistake," but the two most popular client-side JS cookie libraries https://github.com/js-cookie/js-cookie and https://github.com/ScottHamper/Cookies both accept "flexible" expires options, where if you pass them as numbers, they're interpreted relative to now; you have to pass JS Date objects if you want to use an absolute timestamp. If you try that with the Cookie Store API, you're screwed.)
Happy to try. https://github.com/w3ctag/design-principles/issues/425 has some further discussion why this is a good idea.
@ayuishii wasn't there a recent conversation about this between you and...?
