Repository navigation
proposal: deprecate @std/datetime in favor of Temporal #7262
Description
Temporal is stable as of Deno 2.7, so I propose we deprecate @std/datetime. This was already the stated plan in #4804: "It is likely that most of datetime APIs will be deprecated after Temporal is available." That condition is now met.
Why now
- Deno 2.7 (February 2026) shipped Temporal unflagged, following Chrome 144.
@std/datetimeis unstable at 0.225.7, so deprecation carries no semver cost.- The package has 60 dependents on JSR. The earlier we point them at Temporal, the fewer migrations we cause later.
What Temporal replaces
@std/datetime export |
Replacement |
|---|---|
dayOfYear |
Temporal.PlainDate.prototype.dayOfYear |
isLeap |
Temporal.PlainDate.prototype.inLeapYear |
weekOfYear |
Temporal.PlainDate.prototype.weekOfYear |
difference |
Temporal.PlainDate.prototype.since / until |
SECOND, MINUTE, HOUR, DAY, WEEK |
Temporal.Duration |
format |
Intl.DateTimeFormat / toLocaleString (see below) |
parse |
Temporal.PlainDate.from for ISO strings (see below) |
The one gap: custom format strings
format and parse accept format strings like "yyyy-MM-dd". Temporal has no equivalent: it parses ISO 8601 only, and formatting goes through Intl.DateTimeFormat. I still propose deprecating both, pointing format users at Intl and parse users at ISO strings or a userland library. Keeping a two-function package alive doesn't seem worth the maintenance. If maintainers would rather keep them, the rest of this proposal works unchanged.
Plan
- Settle scope in this issue: whole package, or keep
format/parse. - PR: add
@deprecatedJSDoc tags to every affected export, each naming its Temporal replacement, plus a before/after migration example per symbol so it shows up in the JSR docs. - PR: update the module doc to state the package is deprecated and link this issue.
- Release as 0.226.0 so dependents see the tags in their editors.
- Remove the package in a later release, following whatever grace period the earlier package removals used.
I'm happy to send the PRs for steps 2 and 3 once scope is settled.
Activity
bartlomieju commentedon Jul 31, 2026
Strong agree
deprecation(datetime): deprecate @std/datetime in favor of Temporal
timreichen commentedon Jul 31, 2026
I think
parse()andformat()should be kept for exactly that reason:Temporaldoes not support that functionality. Referring users to userland mods could be applied to most std mods to reduce maintenance, which would defeat the point of having a standard library at all imo.Also, there are many std mods that have just few function exports (toml:
parse()andstringify(), msgpack:decode()andencode(), toml:parse()andstringify(), html:escape()andunescape(), etc.) so export function count should not be a deciding factor.tomas-zijdemans commentedon Jul 31, 2026
The gap is real: Temporal has no format-string API. But keeping format/parse would be.. odd. Both are built on Date (format takes one, parse returns one), so in a Temporal world they'd need a redesign around Temporal.PlainDateTime anyway. That's a new API, not these two functions.
So I'd still deprecate the whole package and file a separate proposal for a Temporal-native formatter/parser.