Why zdate
Why not just use Temporal?
I needed zdate's capabilities long before it was zdate — back then it was a date util folder. I eventually formed a vision, believed I was on to something, and ran with it.
If Temporal had been available, I might never have created zdate. So in a way, the wait for Temporal was a blessing in disguise. Without the wait, I would never have discovered zdate and the great moments that came with it.
If you prefer Temporal's model, it is available now. If not, zdate is available as well.
A Different Model, Not a Wrapper
zdate predates Temporal's release. The proposal was a moving target, so there was nothing to build on — and zdate went a different direction anyway. It represents time as one epoch identity with projected views, and that model makes additional public types unnecessary. Calling zdate a Date or Temporal wrapper would be like calling Postgres a libc wrapper because it uses time().
Most JavaScript date libraries improve the wrapper. zdate replaces the model.
Why It Does Not Delegate to Temporal
zdate's parsing, calendar engines, DST handling, offset resolution, and formatting are part of its public contract. Delegating those pieces would make zdate inherit Temporal's semantics instead of owning its own — and with zdate's model, wrapping Temporal for core behavior adds translation cost and leaks foreign semantics. Platform APIs are used only at the boundaries where they belong: high-precision time capture, Intl reference data, limited interop edges.
zdate is also a library, and that is a different release model:
- bugs are fixed on the package timeline, not the engine adoption curve;
- new formats, calendars, and policies ship without waiting on standards;
- behavior is documented and versioned by zdate;
- applications upgrade deliberately.
Options Keep Ecosystems Healthy
If people stop experimenting with alternate solutions, the first solution becomes the final solution. That is not how healthy software ecosystems grow. zdate exists because it offers a different model and API for working with dates and times. JavaScript developers deserve options, especially in a domain this messy.
Where's PlainDate?
If you want the Temporal model with PlainDate, PlainTime, and the rest of its classes, it is available for public use — zdate is not getting in your way. In zdate's model those concepts are views of one identity, plus two types for the concepts that genuinely stand alone: date-only and time-only values. zdate is not smaller because it handles less. It is smaller because the model carries more.
