Chrono stability?

[coder543]

Looking at the contributions, things seem to have been pretty quiet lately. This comment thread about Diesel 1.0 brings up some concern about Chrono's lack of confidence in its own stability.

Chrono is probably the most concerning here, TBH I'm not sure why they aren't on the path to 1.0.

and

So I'm not sure what to do about this problem. Rust clearly has a 1.0-phobia issue, but Diesel is ready to stabilize it's API, and doing so will be huge for Diesel and for Rust.

and

I guess when Chrono releases a breaking change we'll have to deal with it. :/

are relevant quotes.

Is there any chance that Chrono is ready to update to v1.0? Or is the API still so unstable?

[quodlibetor]

I responded in that comment thread.

tl;dr is that, yes, there are known breaking changes desired. I've been sick since that comment thread happened, but I've been thinking and writing notes on my known blockers to 1.0. @lifthrasiir probably has others.

Some obvious ones:

• Trait revamp -- the existing trait collection doesn't really make sense, a
  bunch of things are inherent methods on a bunch of different concrete types
  instead of being in a trait, the specific way associated types are used makes
  generic programming unecessarily difficult (that's why I haven't implemented
  From<Timelike> for Utc, for example), etc.

  This could be backwards-compatible, but I really want to deprecate/delete the
  existing footgun methods.

• Duration is only positive, making implementing Add/Sub and various
  iterators extremely unergonomic.

• Only one calendar system is supported (although I have no idea how multiple
  calendar systems would be implemented, maybe this would be the domain of a
  different library or would be backwards compatible)

So there are a grab-bag of API changes, new types, and possibly truly
fundamental design decisions that we aren't sure about.

Chrono hasn't been getting a lot of commits because:

• there aren't lots of bugs
• there aren't feature requests, except those ones which require API revamps I
  mentioned above.
• Neither lifthrasiir nor myself have lots of time to idly tool on chrono --
  it's basically good enough for everyone's purposes, while still, sadly,
  containing many deficiencies that we'd like to fix before releasing a 1.0

My plan right now is to write up a bunch of tickets that explain what I think
should be done and see if I can mentor enough people that we have a
continuously improving rust datetime library.

[Ygg01]

@quodlibetor Hi, will chrono work on some level with #![no_std]? I imagine embedded things like electronic watches will have great use for keeping time/date.

[quodlibetor]

@Ygg01 Yeah that's a great point, chrono's date/time manipulation is IIRC always constant space. The only thing that we use std for that might be difficult is formatting and parsing, I don't know how you format without Strings (I guess to a static buffer of some sort?) but we should be able to make that work. Parsing is doable now with static arrays, so I think that should work, although who knows how necessary that would be in no_std contexts.

[Ygg01]

how do you format without Strings

I remember SimonSapon gregor using write! macro and Formatters (e.g. TimeZone output). Dislcaimer: I'm not too intimately familiar with the inner workings of gregor.

If formatting is an issue, perhaps it would be possible to make chrono-core (a no_std subset of chrono) a separate crate, and then have chrono crate depend on it for more advanced stuff, like formatting, etc.

[quodlibetor]

Thanks! Yeah, I agree that knowing that we can support no-std should be a blocker for 1.0. I think that we can already, but I'd like to see a PoC that demonstrates it before we mark anything.

[alex]

Not to revive an old thread, but now that alloc is stable, would having chrono support no_std using alloc be a reasonable intermediate target?

[quodlibetor]

@alex yes alloc/no_std support is definitely a goal.

I do actually have time to work on chrono (I just started a new job a month ago that gives me 20% time for open source) and I have started ramping up more work to get it into a better state.

PRs or thoughts about what is most needed are welcome, feel free to comment in #336 if you've got any specific requests/goals.

[pitdicker]

Closing this issue. At the moment most development is happening on the 0.4 branch, and the plan for the next breaking release is to make it 0.5. See #970 for the 0.5 release planning.