Hey there! Let's tackle your question in two clear parts—first, the impacts of setting a Cookie's expiration time, then the differences between those two code snippets.

When choosing how long a Cookie should last, several key factors come into play:

• User Experience: A longer expiration means users stay logged in or retain their preferences across visits, avoiding repetitive actions like re-authenticating. On the flip side, a too-short expiration can frustrate users who have to log in constantly.
• Browser Storage: Browsers limit the total number and size of Cookies per domain (usually a few dozen Cookies and a few KB total). Long-lived Cookies will occupy this storage until they expire or the user manually clears them.
• Security:
  • Overly long expiration: If a Cookie gets stolen (e.g., via XSS), attackers can impersonate the user for an extended period—this is especially risky for sensitive session Cookies.
  • Short/ session-only expiration: Session Cookies (which expire when the browser closes) are safer for sensitive actions, as they reduce the window of opportunity for misuse.
• Server Load: Short expiration times mean more frequent re-authentication requests, which adds load to your server. Longer-lived Cookies can reduce these repeated requests.
• Data Freshness: If your Cookie stores dynamic information (like temporary user preferences), a long expiration might serve stale data to users who expect updated settings.

Let's break down performance and code style for your two examples:

Performance #

There’s zero difference in performance here. JavaScript evaluates the arithmetic in the first snippet (1000 * 60 * 60 * 24 * 365) at runtime (or even during compilation, as it’s a constant expression) to get 31536000000—exactly the hardcoded value in the second snippet. Both end up doing the same work under the hood.

Code Style & Maintainability #

This is where the real difference lies:

• Snippet 1: var expires = new Date(new Date().getTime() + 1000 * 60 * 60 * 24 * 365);
  • Pros: Extremely readable. Anyone glancing at this can immediately tell it’s calculating 1 year (1 second → 1 minute → 1 hour → 1 day → 365 days). If you need to adjust the expiration later (e.g., change to 30 days), you just swap 365 for 30—no math required, and it’s hard to make a mistake.
  • Cons: Slightly longer than the second snippet, but that’s a tiny tradeoff for clarity.
• Snippet 2: var expires = new Date(new Date().getTime() + 31536000000); // one year in milliseconds
  • Pros: More concise.
  • Cons: Without the comment, the number 31536000000 is completely opaque. A new developer (or even you, six months later) won’t know what that number represents unless they do the math themselves. If the comment is removed or incorrect, this becomes a maintenance headache.

One quick side note: Both snippets assume a 365-day year, which doesn’t account for leap years. For most use cases, this is negligible, but if you need an exact 12-month expiration (including leap days), you’d need a more robust date manipulation approach (e.g., adding a year directly to the date object instead of milliseconds).

内容的提问来源于stack exchange，提问作者Laurentiu Stamate