I would like to implement native support for timestamp precision
This ticket is exactly the issue that I've been having: https://github.com/prisma/prisma/issues/15516
I have the time and would like to complete it. If there's anyone that has experience contributing to similar changes to Schema mappings in relation to queries, any help intuitions on where to start / similar tickets to look at. Thank you!!
GitHub
Native support with timestamp precisions Ā· Issue #15516 Ā· prisma/...
Problem Most of the database supporting nanosecond(db.Timestamp(6)). However, JS date can only hold up to milliseconds. The precision is lose when orm doing the transformation. Suggested solution T...
3 Replies
You've gone full bot mode! Let me fetch that AI answer for you ASAP.
I understand you're interested in contributing to Prisma to implement better support for timestamp precision, specifically related to the issue described in Native support with timestamp precisions.
This is indeed a known limitation in Prisma. JavaScript's Date object can only handle millisecond precision (3 digits), while many databases support microsecond (6 digits) or even nanosecond (9 digits) precision for timestamps.
Based on the knowledge sources, here are some insights that might help you get started:
1. The issue is well-documented across several GitHub issues. In issue #10497, a user describes how databases approximate timestamps during insertion but use exact comparisons during selection, causing Prisma to fail when working with high-precision timestamps.
2. There was a change in precision handling between Prisma versions 4.3.1 and 4.4.0, as mentioned in issue #15593, which might be relevant to your work.
3. The Prisma team has been working on native database type support as part of a larger effort (see issue #446), which includes better handling of date and time types.
4. There's also ongoing discussion about supporting TC39 Temporal API in issue #16119, which would provide better handling of temporal data in JavaScript.
For contributing to this specific feature, you would likely need to:
1. Understand how Prisma currently handles DateTime fields and their conversion to/from database types
2. Modify the Prisma engines to support higher precision timestamps
3. Implement a solution that either uses a specialized library (like the suggested Google PreciseDate) or represents high-precision timestamps as numbers
The Prisma engines code is located in the prisma-engines repository, as mentioned by a cont
ributor in issue #3287: "Generally types need to be implemented in our Prisma Schema Language, code can be found here as part of our Engines: https://github.com/prisma/prisma-engines/"
Unfortunately, the knowledge sources don't provide specific guidance on the exact files or components you would need to modify to implement this feature. You might want to:
1. Look at similar PRs in the prisma-engines repository
2. Reach out to the Prisma team directly through their community channels
3. Start by exploring how the current DateTime handling is implemented in the codebase
This is a complex feature that would require deep understanding of both the Prisma internals and database timestamp handling, but it would certainly be a valuable contribution to the Prisma ecosystem.
š¤ Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly.
In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.
Hey š
Thank you for your willingness to work on this feature.
Did you had a look at our contributing guide, this should give you some idea on how to get started
https://github.com/prisma/prisma/blob/main/CONTRIBUTING.md
GitHub
prisma/CONTRIBUTING.md at main Ā· prisma/prisma
Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB - prisma/prisma
@Nurul Thank you for responding. What I'm after is someone on the prisma team that knows where i could get started on implementing proper microsecond precision support in the prisma engine. Or to get some insight into similiar tickets that have changed default return types or allowed for options for return types (or offered different options for return types)