I know that the in-tree time crate has moved here. I also understand that there are some features that fit better as a library instead of in-tree, so people who know what they’re doing can focus on the quality of those libraries, instead of leaving bad, inflexible APIs in the standard libraries . But there are some cases where I think it’s good to have leave a bit of those inflexible APIs in the standard libraries while focusing on the powerful, flexible API in an external library. For example, with the moving of the time crate out of tree, Rust is one of the first languages where I actually have to install an external crate just to get the current time. I feel like basic methods like these should be added back to the standard libraries.
1 Like
The "“chrono” crate is usable. Basic time and date access are:
use chrono::{UTC, Local, DateTime};
let utc: DateTime<UTC> = UTC::now();
let local: DateTime<Local> = Local::now();
That has most of the usual functions for a time-zone aware date/time. it provides standard types for date, time, and date-time, both naive and time zone aware. Functionality is comparable to Python’s “datetime” module. It’s all Rust code, not a wrapper on old C code. There are two other Rust date/time libraries, but they were never converted to Cargo-compatible crates, so they’re not easily usable at this point.
What about adopting “chrono” into the standard library? It’s important that the underlying types for date and time be standard, to avoid painful compatibility problems. More functions on the types can always be added later. (I’m writing some parsing functions.)
1 Like
I’m not sure I see why this is important. Why should it be in the standard libraries?
As I see it:
Downsides to in-tree
- Having an inflexible, not-well maintained in-tree library would be bad
- Not having it in-tree pushes others into using and maintaining better and more flexible crates
Upsides to in-tree
- Other languages do not require an external crate for the current time
- “basic methods should be in-tree”
The two downsides seem pretty clear to me, whereas looking at the upsides, they seem a bit… flimsy. Especially considering how easy cargo makes it to use external crates.
Can you elaborate on why you want it in-tree?
I really don’t have any good arguments here. It’s a gut reaction to “I need to get the current time. Wait, I have to install an external library just to get the current time? That’s crazy!”. Note that I don’t feel like this every time I run into something I need but isn’t in-tree. For example, when I needed a BigInt and I realized it had been removed, my gut reaction was “Well, this is inconvenient, but it makes sense”. Again, that’s a weak argument, but that’s what I was thinking.
To provide some more context, I’m talking to the guy who runs codeforces.com, a popular algorithms competition site, to allow the use of Rust on the website. He agreed and asked me to write some code snippets he could use for benchmarking. Originally I had used Rust’s built in benchmarking features, but he had his own benchmarking system set up so that each language could be compared with the same facilities. So I had to benchmark the old fashioned way, by getting the time before and after the code and subtracting it. At this point I converted the project to cargo, and resent him the code. I honestly felt a bit embarrassed explaining to him why I converted a one file program that I can build with rustc to a multi-file program with a package manager that pulls a dependency and builds the code just to get the current time. None of the other languages had to do anything like that.
But now that I think about it more, I wouldn’t have been as upset if the process was something like cargo install time, and after that the time crate is installed globally and the original code would be able to use extern crate time without using cargo. This is how things work with Python right now; you can just install libraries and then import them. Maybe getting something like that working is a better solution than bringing the time or chronos crates in-tree.
1 Like
I think long-term we all want a great in-tree library for time, but we just don’t know what that looks like right now, so we’re letting the community solve the problem first.
1 Like
The standard library does provide std::time::Duration::span for measuring the time it takes to execute something, by the way.
As @Gankra says, time was mainly moved out of tree because it is not great. Similarly, chrono is still quite new, and there’s enough code in std that we want to perfect, and adding time handling (which is surprisingly hard to get right) would make 1.0 harder.
2 Likes
Thanks @huon, span will be useful.
It’s good to know that this is something that we’d like to see in-tree eventually, that’s really all I wanted to know.
How about adding some basic function to get system time, like Java’s System.currentTimeMillis()? E.g. as os::get_system_time() of type fn() -> u64. This is quite basic thing available in all OSes and almost all languages out of the box. It covers most basic needs and very simple to implement. And if a user want something more fancy, a time/chrono/whatever crate is available.
And how would this be implemented? On Windows there's multiple clocks, like GetCurrentTime and QueryPerformanceCounter and which one you use depends on whether you're measuring very short durations for benchmarking purposes, or you just want to know the time.
I think it should just do the sanest thing most users want to do. In my experience the most used thing is just simple time in ms since epoch. Its useful both as a simple timestamp and as a makeshift benchmarking tool. If you need something more fancy, you can always opt in to an external crate. And BTW benchmark-level accuracy requirement is not that important for Rust, which already have very nice benchmarking tools included (like Duration::span() and #[bench] tests).
I agree with the OP, it’s too often used basic thing to be dropped from stdlib.
Update: it’s even more strange, IMHO, to have std::time with Duration included in stdlib (with span() method which should measure time internally somehow!), and miss get_some_time() function. It’s just a gut feeling there should be such thing nearby, from user’s point of view.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.