local-time: switch from time to jiff

Cargo.toml

@@ -54,7 +54,7 @@ render-line = ["crosstermion/color", "humantime", "unicode-width"]
 render-line-crossterm = ["crosstermion/crossterm"]
 render-line-autoconfigure = ["is-terminal"]
 
-local-time = ["time"]
+local-time = ["jiff"]
 
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
 [dependencies]
@@ -76,7 +76,7 @@ crosstermion = { version = "0.14.0", optional = true, default-features = false }
 async-io = { version = "2.2.1", optional = true }
 
 # localtime support for render-tui
-time = { version = "0.3.2", optional = true, features = ["std", "local-offset", "formatting"], default-features = false }
+jiff = { version = "0.1.1", optional = true }
 
 # line renderer
 ctrlc = { version = "3.1.4", optional = true, default-features = false, features = ['termination'] }

README.md

@@ -33,8 +33,6 @@ This crate comes with various cargo features to tailor it to your needs.
  * If set, timestamps in the message pane of the `render-tui` will be using the local time, not UTC
  * If set, timestamps of the log messages of the `render-line` will be using the local time, not UTC
  * Has no effect without the `render-tui` or `render-line` respectively
- * **On Unix** one needs to provide flags to rustc when building the binary to acknowledge potential unsoundness: `RUSTFLAGS="--cfg unsound_local_offset" cargo build`
- will do the job, but there are [other ways](https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure) to do that as well.
 * **render-line**
  * Provide a minimal line-based progress renderer which can be limited to a subset of the progress hierarchy.
  * It's like the render-tui, but with far less dependencies and less visual fidelity - all it needs is to move
@@ -50,7 +48,7 @@ This crate comes with various cargo features to tailor it to your needs.
  * If enabled, calls to `render::line::Options::auto_configure()` will configure the display based on whether or not we are in a terminal
  and set its color mode based on what's possible or desired.
  * **signal-hook**
- * If set, and the `hide_cursor` line renderer option is set, the cursor will be hidden **and** *SIG_INT* and *SIG_TERM* handlers will be 
+ * If set, and the `hide_cursor` line renderer option is set, the cursor will be hidden **and** *SIG_INT* and *SIG_TERM* handlers will be
  installed to reset the cursor on exit. Otherwise you have to make sure to call `shutdown_and_wait()` on the `JoinHandle` returned
  to give the renderer a chance to undo the terminal changes. Failing to do so will leave the cusor hidden once the program has already
  finished.
@@ -65,7 +63,7 @@ This crate comes with various cargo features to tailor it to your needs.
  * Works everywhere natively, but has more dependencies
  * You can set additional features like this `cargo build --features render-tui-crossterm,crossterm/event-stream`
  * **render-tui-termion**
- * Use the `termion` crate as terminal backend 
+ * Use the `termion` crate as terminal backend
  * It has less dependencies but works only on `unix` systems
  * to get this, disable default features and chose at least `render-tui` and `render-tui-termion`.
 * **unit-bytes**
@@ -89,7 +87,7 @@ This crate comes with various cargo features to tailor it to your needs.
 * The underlying sync data structure, `dashmap`, does not document every use of unsafe
  * I also evaluated `evmap`, which has 25% less uses of unsafe, but a more complex interface.
  * Thus far it seemed 'ok' to use, who knows… we are getting mutable pieces of a hashmap from multiple threads,
- however, we never hand out multiple handles to the same child which should make actual concurrent access to 
+ however, we never hand out multiple handles to the same child which should make actual concurrent access to
  the same key impossible.
 * If there are more than 2^16 tasks
  * then
@@ -107,7 +105,7 @@ This crate comes with various cargo features to tailor it to your needs.
  * trying to draw beyond the terminal boundary will add a line break automatically, which can cause unexpected overdraw.
  * **fix**
  * count amount of blocks drawn, without ansi codes, and stop drawing at the boundary.
- 
+
 ## Lessons Learned
 
 * `drop()` is not garantueed to be called when the future returns Ready and is in the futures::executor::ThreadPool

src/lib.rs

@@ -34,7 +34,7 @@
 
 Run it with `cargo run --example dashboard` and see what else it can do by checking out `cargo run --example dashboard -- --help`.
 */
 #[cfg(feature = "atty")]
 pub use atty;
 
 #[cfg(feature = "progress-tree")]
@@ -49,7 +49,7 @@
 #[cfg(feature = "progress-tree-log")]
 pub use log::warn;
 
-#[cfg(any(feature = "humantime", feature = "time"))]
+#[cfg(any(feature = "humantime", feature = "local-time"))]
 ///
 pub mod time;
 

src/time.rs

@@ -2,24 +2,23 @@
 mod localtime {
  use std::time::SystemTime;
 
+ use jiff::Zoned;
+
  /// Return a string representing the current date and time as localtime.
  ///
  /// Available with the `localtime` feature toggle.
  pub fn format_now_datetime_seconds() -> String {
- let t = time::OffsetDateTime::now_utc();
- t.to_offset(time::UtcOffset::local_offset_at(t).unwrap_or(time::UtcOffset::UTC))
- .format(&time::format_description::parse("%F %T").expect("format known to work"))
- .expect("formatting always works")
+ Zoned::now().strftime("%F %T %Z").to_string()
  }
 
  /// Return a string representing the current time as localtime.
  ///
  /// Available with the `localtime` feature toggle.
  pub fn format_time_for_messages(time: SystemTime) -> String {
- time::OffsetDateTime::from(time)
- .to_offset(time::UtcOffset::current_local_offset().unwrap_or(time::UtcOffset::UTC))
- .format(&time::format_description::parse("[hour]:[minute]:[second]").expect("format known to work"))
- .expect("formatting always works")
+ Zoned::try_from(time)
+ .expect("system time is always in range -9999-01-01..=9999-12-31")
+ .strftime("%T")
+ .to_string()
  }
 }