English

Developer tools · Unix timestamp converter

Checking a cookie or cache expiry epoch before you ship it

· Why it matters

timestamps debugging web-development

An expiry marker checked against a UTC timeline before deployment
Original ToolAcre vector illustration

Expiry values are computed, rarely read, and wrong in ways that only show up later. This post lists the places absolute epochs appear (Redis, memcached, signed URLs, cookies) and shows how to verify one before it reaches production.

The cache that expired instantly — a computed expiry written in the wrong unit and a hit rate that fell to zero

A cache hit rate collapsing immediately after deployment can come from an expiry computed in the wrong scale. The cache is behaving correctly when it receives an instant decades in the past. Before tuning memory or eviction, inspect the exact number sent by the deployment path.

Compare it with the deployment time and intended lifetime. ToolAcre can render seconds and milliseconds explicitly, making a factor-of-1,000 mismatch visible. Keep the raw command or configuration beside the result; manually replacing the value in production without fixing its calculation guarantees recurrence.

Check whether the failed entries were created with the new release while older entries still hit. That correlation can isolate expiry calculation from unrelated eviction pressure.

Where absolute expiries appear — Redis EXPIREAT versus PEXPIREAT, memcached's thirty-day rule, signed URL expiry parameters and cookie Expires attributes

Absolute expiries appear in many systems, but their units and edge rules are not interchangeable. The workbook listed several named products; the timestamp repository does not implement or document their protocols. Verify each command, query parameter or attribute with its authoritative contract before applying an epoch.

The shared diagnostic remains valid: capture what was sent, identify whether it names an instant, state its unit and convert it. Avoid transferring a rule from one cache command to another because their names look similar. A correctly converted date can still be invalid for the target API.

Absolute expiry APIs differ; verify the specific store, URL signer or cookie contract

A relative TTL answers “how long from the operation?” while an absolute epoch answers “at which instant?” Adding a TTL to current time produces an absolute value; sending the original TTL to an absolute field places it near the epoch. Sending an absolute count to a relative field can preserve data far longer than intended.

Name variables for their semantics, such as `ttlSeconds` and `expiresAtMs`, and convert at the call site whose contract is known. Tests should freeze the reference clock so expected expiry is deterministic. Avoid asserting merely that the result is greater than now; that can pass values with wildly wrong lifetimes.

Time zone traps in expiry — an expiry meant for 'midnight' computed in the server's zone rather than the user's or UTC

“Expire at midnight” is incomplete until midnight’s zone is named. Midnight UTC, server local time and a user’s local midnight can be different instants and even different calendar dates. ToolAcre’s date-time picker treats a zoneless date-time as the browser’s local time and says so.

For infrastructure expiry, an explicit UTC date-time often removes environmental dependence. For a user policy, retain the intended named zone in the scheduling layer before resolving an instant. The converter can inspect the resolved epoch, but it does not choose which midnight the requirement meant.

Store the policy phrase and the resolved instant separately during debugging. That exposes whether disagreement began in requirement interpretation or in subsequent epoch arithmetic.

“Midnight” needs an explicit interpretation before it becomes an expiry instant

Imagine a release at `2025-02-03T10:30:00Z` that should expire exactly one day later. The expected absolute value is 1,738,668,600 seconds or 1,738,668,600,000 milliseconds, yielding `2025-02-04T10:30:00.000Z`. Convert the script’s output under its declared unit and compare.

A value of 86,400 in an absolute-seconds field would render as 1970-01-02, revealing that a duration was sent without adding the release instant. A value multiplied twice by 1,000 may fall outside Date range. Both failures are more informative than a generic “cache missed” metric.

The day-long delta can be asserted directly as 86,400 seconds. This duration check remains stable even if a reviewer’s local rendering differs from the UTC deployment schedule.

Worked example: inspect an absolute expiry from a deployment script

Before merging, expose the computed value in a unit test or dry-run output and inspect it as a date. Also subtract the known reference instant to confirm the intended lifetime. These two checks catch different mistakes: a plausible date in the wrong month and a correct date reached by brittle local assumptions.

Use fixed fixtures instead of the wall clock in assertions. Then test the real serialization boundary so a seconds value is not converted again by a client. ToolAcre serves as an independent human check, not the only automated defense.

What this does not cover — HTTP-date formatting for Expires headers, which uses a textual format rather than an epoch

Some expiry interfaces use textual date formats rather than epochs. This repository generates ISO for display and parses Date-compatible input, but it does not generate protocol-specific header dates. A number converted correctly does not prove a textual header has the required grammar or zone label.

Keep formatting in a dedicated, tested adapter for that protocol. Do not paste a human string into a numeric field or assume an ISO output can replace every wire format. The expiry instant and its serialization are separate layers, and each deserves its own contract check.

Textual expiry formats are separate contracts from numeric epochs

Every absolute expiry should be read once as a human date before release. That brief check catches unit, duration-versus-instant and midnight interpretation errors while the code is still reviewable. It also creates a concrete expected result for regression tests.

Use the converter with the explicit target unit, compare UTC with policy, and fix the calculation rather than the stored symptom. A readable expiry is not sufficient proof of target-API correctness, but an unreadable one should never reach production unnoticed.

Attach the expected ISO instant to the change review, but keep the executable assertion numeric. Human review and machine regression then protect complementary parts of the boundary.