Expand the std::time module

[alexcrichton]

Tracking issue for rust-lang/rfcs#1288

[alexcrichton]

One question raised during review is what representation these types should have on each platform. Currently they all have the native representation (e.g. libc::timeval, LARGE_INTEGER, etc) as this keeps lossless information as long as possible.

As a consequence, however, issues like #29970 come up where the types have the property that basic algebra does not work on them. For example b + 1ns == b may be true (along with other various properties). The reason for this is that the resolution of the native representation varies among platforms, meaning that small increments aren't actually representable.

I think that having a (u64, u32) representation would fix this, but it is a divergence from the platform types and now if a SystemTime is ever handed back to the standard library it'd have to do more conversions. May be worth it though?

[sgrif]

Is there intended to be a public constructor for any of these, or make Timespec public as well? This API as is doesn't provide any way to represent a time that isn't relative to now. It'd be great if there was a std library type that Diesel could return for timestamp database columns.

[SimonSapin]

It’s a bit convoluted, but you can construct a SystemTime with UNIX_EPOCH + Duration::from_secs(unix_timestamp_in_seconds), for example.