Seconds to sane units, sprint arithmetic, ISO 8601 and epoch output - the time math you keep re-deriving in a REPL.
Every developer has typed 86400 into a calculator to remember what a day is. TCalc knows: durations parse from any unit and format to any other - seconds, minutes, hours, days, timecode, ISO 8601, Unix epoch.
The developer layout below ships with the units you actually use; deadline math like "sprint minus time burned" is a single expression.
A ten-digit integer in a log line is a UNIX timestamp: seconds since 1970-01-01T00:00:00Z. A thirteen-digit one is the same thing in milliseconds. Neither is readable, and the usual workflow - paste into a converter site, squint, paste back - is slow enough that people skip it and guess instead, which is how stale-cache bugs survive a whole afternoon.
The two questions that actually come up are what a timestamp means and how long ago it was. The second is a subtraction against now, and it is the one that tells you whether a token expired an hour ago or a fortnight ago.
A bare ten-digit integer is auto-detected as a UNIX timestamp and rendered locally.
How long ago that timestamp was - the question worth asking about a cache entry.
A week out, in machine-readable form, ready to paste into a config file.
Timeout and retry configuration is arithmetic on units nobody does in their head reliably. Three retries at a thirty-second timeout is a minute and a half of worst-case latency before the caller gives up, and that number needs to be smaller than whatever upstream deadline you sit behind. Getting it wrong produces the failure mode where a retry storm outlives the request that triggered it.
Rate limits invert the same calculation: a budget of a thousand requests an hour is one request every 3.6 seconds, and knowing that figure is what lets you size a queue instead of discovering the ceiling in production.
Worst-case latency for three retries at a thirty-second timeout.
A thousand requests per hour expressed as the interval between them.
A raw millisecond value from a config file, made readable.
Sprint planning mixes two units that look similar and are not: calendar duration and effort. Three sprints is forty-two calendar days, but it is not 42 × 8 hours of capacity, because weekends and everything that is not feature work sit inside that span. Keeping effort in work days and duration in calendar days, and converting explicitly between them, is what stops an estimate from being quietly optimistic by a factor of nearly three.
The other habit worth having is adding the buffer as an expression rather than as a feeling. Twenty per cent on an eighty-hour estimate is sixteen hours; writing it down makes it a decision that can be defended or removed, instead of padding that nobody can audit.
Three two-week sprints as calendar duration.
The calendar date two sprints from now.
An eighty-hour estimate with an explicit twenty per cent buffer.
Sprint remaining after three days and change of work.
That timeout value, in human units.
A million seconds, converted with one keypress.
Days to minutes - or seconds, or milliseconds.
Type the value with its unit: 10000s displays as 2h 46m 40s in compact format, or as 2.7778h in decimal hours. No dividing by 3600 in your head.
Yes - datetime results can be formatted as ISO 8601 or Unix epoch, and durations down to milliseconds. Switching formats is instant.
Yes: subtract dates to get the gap (2026-12-24 − 2026-07-17 = 159 days) or subtract burned time from a sprint: 14d − 3d 4h = 10D 20h.