Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for converting to/from jiff::Timestamp #3826

Closed
wants to merge 1 commit into from

Conversation

snaggen
Copy link

@snaggen snaggen commented Sep 11, 2024

This Provides easy convertion from/from DateTime to/from jiff::Timestamp by adding simmilar convertion functions as exists for time and chrono

@snaggen snaggen requested review from a team as code owners September 11, 2024 13:32
@landonxjames
Copy link
Contributor

Hi snaggen, thanks for the contribution! We are always very hesitant to tie our public APIs to the APIs of other crates, especially ones like jiff that are not yet 1.0 since we would be tied to supporting that indefinitely. Due to that we unfortunately will not be able to accept this contribution.

@BurntSushi
Copy link

@landonxjames How do y'all deal with other dependencies that aren't 1.0 yet? e.g., chrono and time.

@landonxjames
Copy link
Contributor

@BurntSushi the answer to that is a two parter, we recently changed our tactics on supporting things like this:

Previously we just accepted them behind feature flags and moved on. That caused some problems. Even though the dependency was behind a feature flag breaking changes could still impact our customers because the flag says nothing about which version of the dependency it is gating. Since the unstable attribute isn't yet available to library authors we don't have a great way to telling users that this feature could break at any point (besides the parent crate just not being 1.0, but we still strive to minimize breaking changes in our pre-1.0 libs).

Now we have changed our strategy a bit. For external libraries that are pre-1.0 that have to be part of our public API (mostly Hyper and the Http types) we have a feature flag that is tied to the version of the library (see the http-02x and http-1x flags in aws-smithy-runtime-api for an example). This is safer and provides a more reasonable upgrade path for users, but is also a lot of work and maintenance on our end. Due to this new strategy we are trying to minimize the number of pre-1.0 crates we support to lower our own burden.

Hopefully all this makes sense. We are a small team and have to be very careful about the maintenance burden we take on.

@BurntSushi
Copy link

Thanks for the response! That all makes sense, and I would probably do the same. :)

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.

3 participants