feat: add option for using Temporal timestamp representation #1219
+1,028
−19
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stephenh
approved these changes
Oct 19, 2025
Owner
stephenh
left a comment
stephenh
left a comment
There was a problem hiding this comment.
Love to see temporal support; thank you @confusingstraw !
Looks like there was a lint error; can you take a look at that, and then I'll hit merge?
Contributor
Author
|
Should be fixed. Hopefully adding a global type polyfill for the integration test environment is acceptable. |
Owner
|
Yep, lgtm; thank you! |
stephenh
pushed a commit
that referenced
this pull request
Oct 21, 2025
# [2.8.0](v2.7.7...v2.8.0) (2025-10-21) ### Features * add option for using Temporal timestamp representation ([#1219](#1219)) ([c46c020](c46c020))
Owner
|
🎉 This issue has been resolved in version 2.8.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
stephenh
pushed a commit
that referenced
this pull request
Oct 22, 2025
This PR fixes an issue I introduced in the initial `useDate=temporal` PR [here](#1219). The generated code for `toTimestamp` was dividing the `epochMilliseconds` twice, causing the date to get truncated to `1970-01-01`, so the tests would seem to work for dates. There was _also_ a bug in how `nanos` was calculated: ```typescript Temporal.Instant .fromEpochMilliseconds(instant.epochMilliseconds) .until(instant); ``` since we were deriving the start date from `epochMilliseconds`, so the remainder only included micro/nanoseconds (milliseconds were always `000`). The PR addresses the first issue by ensuring we only divide once, in the generated `seconds` code. It fixes the latter by using the built-in [Temporal.Instant.prototype.round](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/Instant/round) method to round to the nearest second without needing to do any explicit math. Lastly, it also updates the tests, as the `toStrictEqual` check was succeeding even for `Instant`s whose string representations were clearly different, so now we will test against the output string.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for a new
useDateoption:temporal. When used, it will cause the generated code to use the new Temporal.Instant object.The advantages of supporting the new API include higher precision timestamps (up to nanosecond precision, which aligns with the Protobuf spec), as well as a variety of Temporal-related utilities, such as Duration. In a future update, it may be useful to add a similar flag for using the
Temporal.Durationobject forDurationrepresentation.