Skip to content

Conversation

@dbascoules
Copy link
Contributor

Resolves Oracle part of #866.

@wangxiaoying
Copy link
Contributor

Hi @dbascoules , thanks for the PR!

Since the goal of this PR largely overlaps with an earlier one #868, it now has some conflicts with the main branch. Also, the code must be formatted to pass the CI, you can do it using cargo fmt.

…(~290 000 years vs. 585 years respectively)

timestamp_nanos_opt() support only dates between 1677 and 2262
@dbascoules
Copy link
Contributor Author

Hi @wangxiaoying,
I just (dumb)rebased the branch on main but not even tried to test/rebuild against my use-cases.
I'll try to do it when having time...

Copy link
Contributor

@wangxiaoying wangxiaoying left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not change the precision to microsecond for types like NaiveDateTime since not all the databases support it. Instead, you can use the corresponding wrappers with microsecond precision implementation and leave the original types as nanosecond precision.

You can checkout this thread for previous discussions.

@dbascoules
Copy link
Contributor Author

Before continuing this PR, I suggest that we introduce tests (see #871) to cover all these type conversions and avoid introducing regressions.
I believe this would simplify spec writing and make our communication clearer.
@wangxiaoying what do you think ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants