Generally this looks good. I assume the motivation for naming the feature jiff-0_2 is to provide (eventually) jiff-0_3 and jiff for a future 1.0 release? I would like to avoid an implicit commitment to support multiple versions. Though I guess we can always remove supported versions while our own version is 0.x (we would need to bump the 0.x to 0.${x + 1}`, of course).
Thoughts?

PS: not asking you to change anything yet, just trying to understand motivations and tradeoffs.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.14%. Comparing base (9538e8a) to head (1186d47).

@@            Coverage Diff             @@
##             main    #1154      +/-   ##
==========================================
+ Coverage   96.10%   96.14%   +0.03%     
==========================================
  Files          35       35              
  Lines        1388     1399      +11     
==========================================
+ Hits         1334     1345      +11     
  Misses         54       54              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Generally this looks good. I assume the motivation for naming the feature jiff-0_2 is to provide (eventually) jiff-0_3 and jiff for a future 1.0 release? I would like to avoid an implicit commitment to support multiple versions. Though I guess we can always remove supported versions while our own version is 0.x (we would need to bump the 0.x to 0.${x + 1}`, of course).

I came across this idea in, for example, https://github.com/sfackler/rust-postgres/blob/master/postgres/Cargo.toml where it seemed like a nice approach for supporting multiple crates - in the case where it's implementing trait implementations for your own traits and third party types.

I firstly thought it would make it easier to transition between jiff 0.2 and jiff 1.0, because it unties the strict need to update both libraries simultaneously.
Secondly, the approach could allow support for multiple versions on a longer-term basis, but I can both see how this is maybe not ideal from your point of view. Also for jiff, since 1.0 is expected to be an LTS version, it's very much not necessary here.

But at the end of the day, the benefit here is definitely minor, and I can switch to just calling the feature jiff.

Updated the feature name as jiff.

Also updated the Timestamp tests to verify that the jiff and wkt values both represent the same point in time (otherwise, it proves that the first value in the test case was converted to the other, but not that the test case values were wisely chosen).

I think we are going to wait until jiff gains more traction before taking a dependency on it. It looks very promising, and once it reaches 1.0 I think the case is easier. For now, we want to be conservative on adding extra deps to our public API (even if protected by feature flags).

I hope you do not feel like you wasted a lot of time on this. We are still refining our thinking about how to manage deps for Rust.

No hard feelings here - it's fair. Also given the beta nature of both these libraries at this point in time, it's not going to inconvenience a lot of users.

I'll close this PR for now, but you can use it as reference code in the future if you want.