feature request: Human friendly time formatting strings

[max-ishere]

I really need the better TZ support of jiff, but it doesn't have those nicer formatting strings time has. I prefer these readable ones because they're easier to write and read in the config file.

fmt = "[weekday repr:short], [month repr:short] [day] [year] [hour repr:12]:[minute]:[second] [period]"
fmt = "%a, %b %d %Y %I:%M:%S %p" # some C++ library that waybar uses

It doesn't really matter what format you go with, I just don't wanna guess that %I means 12h hour value.

Maybe it would make sense to move the parser to a separate crate, that way there can be a standard parser that can be shared across different time crates, and the time crates could just read the tokens and format accordingly.

One other feature I really want is to get the precision of the output, that way I can automatically set the sleep() duration without having to specify it in the config.

[BurntSushi]

At this time, I do not have any plans to support something like what time has. I'm not a huge fan of strtime-style formatting either, but I went with it because it has near ubiquitous support (in one form or another) in nearly all software ecosystems. That is, despite it being not-great, most folks are familiar enough with it. In contrast, having used time's approach, I found that it swung too far in the opposite direction for my own taste. And supporting both is not really in the cards from a maintenance bandwidth perspective.

More to the point, the strtime support in Jiff is meant to be a sort of utility tool that's sometimes useful. If you're looking for something more sophisticated, I'd suggest using icu. (You can use Jiff with icu, although the experience isn't great right now.) That way, you'll get all the Unicode goodness.

One other feature I really want is to get the precision of the output, that way I can automatically set the sleep() duration without having to specify it in the config.

Say more please? Can you show an example?

[max-ishere]

Welp, looking at the code, the easiest thing I could do is write a translator from OwnedFormatItem into a string...

If there was an AST, then it would be easier to support multiple string formats that map into the same AST tokens...

[BurntSushi]

ASTs and all that are specifically avoided for strtime in Jiff. Everything is done in one pass for performance. (And this actually helps quite a bit in comparison to time and chrono. Jiff does pretty well in comparison to them.)

That is part of why the format is the way it is, I think. If you look at the "old school" C implementations of it, they are similar to Jiff's: everything is done in one pass without any intermediate structures.

I really do suggest looking at icu. icu is the closest thing to a "correct" way to approach this because they follow Unicode's recommendations. From Unicode's perspective, things like strtime (and what's in time) are blasphemous.

[max-ishere]

Ok, I'll look into it... I am assuming I can get some kind of timestamp from jiff and use it in icu? I am writing a module for a bar and I need to parse the config, get the format string and then display it in a label on the bar.

[max-ishere]

I think for now it's not very high on the priority list so I'll just use the % stuff and come back later to make it more human friendly.

#[derive(Deserialize, Debug)]
#[serde(rename = "snake_case")]
pub enum TimeFmtFormat {
    #[serde(rename = "strftime", alias = "%")]
    StrFTime(String),
}

[BurntSushi]

Yeah I linked to an example of Jiff and icu integration in my first comment. It's not great, but it will work just fine. I'd like to have a jiff-icu (or whatever) crate that handles the integration points in the future, but I haven't gotten to it yet.

[max-ishere]

Thanks