std::time is stunted

[Manishearth]

The only thing std::time contains is Duration, which isn't too useful on its own. The real meat of it is in ::time.

Perhaps one should be moved into the other?

Alternatively, we can add some docs to Duration that explain how to work with it. One common way of getting a Duration is to subtract two instances of time::now().to_timespec()s, however this is completely not obvious on std::time. I don't mind adding these docs.

[aturon]

cc me

[bluss]

It seems to be a nice model where libstd defines a common type or trait and 3rd party packages can use those. The benefit is possibly better cross-library compatibility. The only hazard is that the libstd parts need to be well designed, so that they are actually useful and will be used by other packages.

[nodakai]

Some folks attempts to use Rust to write a OS kernel or a Linux kernel module without libstd (and I'm really excited to see progresses in this area.) When they need to define an interface involving timeout (eg. include/linux/ktime.h,) time::Timespec, as well as std::time::duration::Duration in theory, will be valuable. (However time::Tm will be meaningless without tz database usually maintained by OS.)

I think libstd should be an umbrella crate linking to other smaller crates in the standard library.

[Manishearth]

Any ideas on what should be done then? I'm willing to RfC this if necessary, but a general idea of which way we should go (moving into or out of std) would be nice. If people want the status quo, I'll try to add some doc comments.

[pnathan]

Declaration:

std::time should allow datetime manipulations (arguably it should be std::datetime). That would provide a clear & obvious place to find time code. Having the time code in two separate locations doesn't make things obvious.

Further, a cursory inspection suggests that the types in each module are different, inhibiting the natural coupling in time modules.

[steveklabnik]

This is effectively a duplicate of rust-lang/rfcs#619 today, so I'm giving it a close.