burntsushi
I love to code.
I’m on the uv team. I am quite partial to this approach as well. Alas, it’s difficult culturally to pull this off in a pre-existing ecosystem. And in the case of Python at least, it’s not totally clear to me that it would avoid the need for solving NP hard problems. See my other comment in this thread about simplifying PEP 508 marker expressions.
Other than avoiding needing a SAT solver to resolve dependencies, the other thing I like about Go’s approach is that it makes it very difficult to “lie” about the dependencies you support. In a maximal environment, it’s very easy to “depend” on foo 1.0 but where you actually need foo 1.1 without issues appearing immediately.
Interestingly, dependency resolution is not the only NP hard problem uv tries to solve. During development, it also became clear that we needed some way to simplify PEP 508 marker expressions and ask questions like, “are these marker expressions disjoint?”
uv 0.3 introduces a cross platform lock file: https://docs.astral.sh/uv/concepts/projects/#lockfile
More precise details on the compatibility of uv pip with pip are documented here: https://docs.astral.sh/uv/pip/compatibility/
Yeah this is a tough one. I’m not sure the right thing to do is for me to go around blasting PRs at those projects. They’re probably already carrying support for both chrono and time, and asking them to support a third that is brand new is a bit of a stretch I think. Especially since I’ve promised breaking changes in the not-too-distant future. (Although I would like to do a Jiff 1.0 release about 1 year from now and commit to stability.) At least, I know I’d be hesitant if I were on the other side of it. But maybe folks are more flexible than me, I’m not sure.
I’ve been noodling on just adding these integrations to jiff itself. I do worry that if I do that, then the integrations will always stay with Jiff, even at 1.0. But maybe there just isn’t another feasible choice.
But, why do you mention humantime? humantime doesn’t have any integrations with time or chrono. humantime is more like a thin wrapper on top of std::time::Duration and std::time::SystemTime to make parsing and printing a bit nicer.
You should absolutely not need to handle ISO 8601 and RFC 3339 manually. They are supported via the Display and FromStr trait implementations on every main type in Jiff (Span, Zoned, Timestamp, civil::DateTime, civil::Date and civil::Time). It’s technically an implementation of a mixture of ISO 8601, RFC 3339 and RFC 9557, but the grammar is specified precisely by Temporal. See: https://docs.rs/jiff/latest/jiff/fmt/temporal/index.html
OK, I’ve beefed that example up a little bit: https://github.com/BurntSushi/jiff/commit/08dfdde204c739e38147faf70b648e2d417d1c2e
I think the comparison is a bit more muddied now and probably worse overall to be honest. Maybe removing DateTime<Local> is the right thing to do. I’ll think on it.
It’s a subtle comparison to make… Probably most people don’t even realize that they’re doing the wrong thing.
OK, fair enough. What should it say instead? Just omit the mention of DateTime<Local>? I used it because it’s literally the only way to derive(Deserialize) in Chrono in a way that gives you DST aware arithmetic on the result without getting time zone information via some out-of-band mechanism.
Again, to be clear, I’m not saying it’s impossible to do. But in order to do it, you have to build your own abstractions. And even then, you still can’t do it because tzfile doesn’t give you enough to do it. And tzfile has a platform specific API with no caching, so every time you parse a datetime with a tz ID in it, it’s completely reloading the TZif data from disk.
Some of these things are implementation quality issues that can be fixed. Others are library design problems where you can achieve your objective by building your own abstractions. Like do you really not see this as something that shouldn’t be mentioned in a comparison between these crates? You must recognize the difference between what you’re doing and just plopping a Zoned in your struct, deriving Serialize and Deserialize, and then just letting the library do the right thing for you. And that mentioning this is appropriate in the context of the “facts of comparison” because it translates into a real user experience difference for callers.
Time zone transition changes happen all the time. Once you start storing datetimes in the future, you’re in a bit of a precarious position here. Moreover, this is a standardized interchange format that other libraries will know how to read/write. (It’s relatively newly standardized, but has been used in practice among other datetime libraries.)
I think you also glossed over some of my other points. How do you write your serialization code using Chrono? Does it work with both chrono-tz and tzfile?
The point is almost never about “it is literally impossible to accomplish task foo,” but rather, it matters how it’s approach and how easy it is to do. And if you have to rely on your users having very specific domain knowledge about this, it’s likely there will be errors. As my design docs state, I didn’t only make Jiff to offer more functionality. I also made it because I felt like the APIs could be better. That’s a very subjective valuation, and I find arguments of the type, “well I can just use the old library in this way as long as I hold it right and it actually works just fine” to be missing the forest for the trees.
