Bttf is a command line datetime Swiss army knife | Hacker News Reader

Bttf is a command line datetime Swiss army knife

github.com

183 pointsburntsushi99 comments

I'm the author of Bttf. I just wanted to share a really cool example of something that Bttf can do that I _think_ is kinda hard to do otherwise. (And also, I want to make an assertion about it and I hope this will lead to me being wrong and learning something new.)

The use case is: "I want to see a list of all files in a repository, sorted in ascending order of when it was most recently changed according to source control. I also want to highlight the time with color, make it be in local time and format it in my own bespoke way using strftime." Here's the full command (run from the root of https://github.com/BurntSushi/ripgrep):

    $ git ls-files |
        bttf tag exec git log -n1 --format='%aI' |
        bttf time in system |
        bttf time sort |
        bttf time fmt -f '%a %Y-%m-%d %H:%M:%S' |
        bttf untag -f '{tag}|t{data}'
    ...
    Thu 2025-10-30 13:30:14 crates/ignore/Cargo.toml
    Sat 2025-11-29 14:11:38 crates/core/flags/lowargs.rs
    Wed 2025-12-17 11:38:12 tests/misc.rs
    Wed 2025-12-17 11:38:12 tests/util.rs
    Thu 2026-02-12 20:39:46 crates/ignore/src/default_types.rs
    Fri 2026-02-20 16:06:29 crates/core/flags/config.rs
    Fri 2026-02-27 11:25:19 GUIDE.md
    Fri 2026-02-27 11:25:19 crates/core/flags/defs.rs
    Mon 2026-05-25 23:56:53 CONTRIBUTING.md
    Tue 2026-05-26 08:32:43 AI_POLICY.md

Or even ask for a specific time window:

    $ git ls-files |
        bttf tag exec git log -n1 --format='%aI' |
        bttf time in system |
        bttf time cmp ge 2026-01-01 |
        bttf time cmp lt 2026-04-01 |
        bttf time sort |
        bttf time fmt -f '%a %Y-%m-%d %H:%M:%S' |
        bttf untag -f '{tag}|t{data}'
    Thu 2026-02-12 20:39:46 crates/ignore/src/default_types.rs
    Fri 2026-02-20 16:06:29 crates/core/flags/config.rs
    Fri 2026-02-27 11:25:19 GUIDE.md
    Fri 2026-02-27 11:25:19 crates/core/flags/defs.rs

If you run this on a big repository, it will take quite a lot of time because `git log -n1` takes a long time. I think this is the fastest way to get the most recent commit time on a single file? (That's the assertion that I hope someone can correct me on!) In any case, `bttf tag exec` is using parallelism under the hood to make this even faster.

Thank you for making cool stuff and sharing it with us.

Quick Note: You can put the pipe operator where your backslash is and you won’t have to escape the newline character. Works in bash, zsh and ksh (what I’ve tested).

Oh nice thank you!

This is pretty neat. My proficiency with the command line is woefully underdeveloped and seeing examples like this help me see the possibilities.

> I think [`git log -n1 -- <path>`] is the fastest way to get the most recent commit time on a single file?

In terms of machine time? I'd guess so, but I'd also guess calling it for each of `git ls-files` is not the fastest way to get the most recent commit of all the files in a typical scenario (large repo, recent time of interest, most files not changed that recently). And especially if you're okay assuming the most recent commit by parentage is the one you want (even if parentage doesn't match chronological order); then filtering with `git log --name-only --since` (no path argument) seems better. A `git log` post-processing script could also stop early if it's seen a commit for each the files of interest (again, assuming you don't want to return a later date that is attached to an ancestor commit).

Anyway, cool tool, and it's rare that I would actually care about the machine efficiency of this pipeline enough to bother with the approach I just described.

Yeah totally right. I just don't know enough about git to figure it out. But a sibling commenter helped a lot.

And yeah perf probably doesn't matter much. But, like, running my approach on the Rust compile repo takes at least minute on my beefly (if a little dated) machine. But lukasgelbmann's approach only takes about 11 seconds. That's a big improvement.

Yeah though, perf here may not matter much. It's just an example use of bttf that is less than instant. (And it's not really bttf. It's my examples access pattern of git.)

> “If you run this on a big repository, it will take quite a lot of time because `git log -n1` takes a long time. I think this is the fastest way to get the most recent commit time on a single file? (That's the assertion that I hope someone can correct me on!) In any case, `bttf tag exec` is using parallelism under the hood to make this even faster.”

Instead of running `git log -n1` on every file, I think you can walk through the commits backwards, skipping any files that have been seen. Something like this (these two commands could be followed by bttf commands):

  git log --pretty=format:"DATE:%aI" --name-only |
  awk '/^DATE:/ {date=substr($0, 6); next} $0!="" && !seen[$0]++ {print date, $0}'

This seems to run much faster. The only problem is it'll include files that have been renamed or removed. I got an AI to fix that too, but it starts getting awkward (still fast though!):

  git ls-files |
  awk '
    # Read all existing files from git ls-files into an array
    NR==FNR { lsfiles[$0]; next }

    # Process the git log stream
    /^DATE:/ { date=substr($0, 6); next }
    $0!="" && ($0 in lsfiles) && !seen[$0]++ { print date, $0 }
  ' - <(git log --pretty=format:"DATE:%aI" --name-only)

Oh interesting! That is indeed quite a bit faster.

I'll have to noodle on this one. `bttf tag exec` works with arbitrary commands that can print any kind of date. But your approach require a different access pattern. I can either specialize the use case in bttf (blech) or I can figure out how to generalize your approach.

I think the key issue here is probably that it isn't line oriented. bttf composes well, but only when you have a one-to-one relationship between date and data. (Or a many-to-one is also supported, but it's many dates to one datum, not one date to many datums.) So maybe that relational model is worth figuring out how to streamline. Then I think this use case would work better.

Also, thank you! This is exactly the kind of reply I was hoping for! :D

Pretty recent Git versions have git-last-modified(1) which can list all files along with the last modified commit.

Oh neat! TIL about `git last-modified`. That looks like a fun one to explore. Thank you.

Respect for programming this. I did some date/time calculations a few years ago using Perl and it was full of corner cases and trouble. Did I enjoy it? I enjoyed seeing it work. Hopefully with the right answers! This tool looks great.

Perl's DateTime module was pretty solid, IIRC. One of the things I miss about using Perl.

Yes, I agree. It was magic to me really. I still love Perl.

I remember when biff was what we ran in a CSH to be informed of new email. I don’t remember if this was a local UCB tool or if it was part of BSD.

I am a happy user of dateutils [0], but I will try out Biff and see which one is more ergonomic.

[0]: https://www.fresse.org/dateutils/

Yes! dateutils is great! I have a comparison about it here: https://github.com/BurntSushi/biff/blob/master/COMPARISON.md...

The comparison with GNU date is also likely informative.

I think I would have instead changed the name to `marty`, who, in time, learned to think fourth-dimensionally.

Maybe. But it's longer and already taken on crates.io.

$> brew install bttf Warning: No available formula with the name "bttf

same with macports

so it is pretty much not existing, cause I am not getting some binaries and drop them into some folder for some command line tool

It's a cargo package. There's an installation readme...

Everyone talking about "biff" should be aware that it's actually "bttf" like "back to the future"

Don't jump to the conclusion that they all mis-read the name several hours ago, though.

* https://news.ycombinator.com/item?id=48310191

Not to be confused with "biff" from "back to the future"

There's a commit message that says otherwise:

> The new name, bttf, is a backronym for "biff, time to format!"

It credits this comment:

https://news.ycombinator.com/item?id=48307552

However, "back to the future" might be more memorable. I'm surprised they didn't see it.

At my last company, I wrote a little tool for pretty printing our JSON logs. You pipe into it and it prints out. It's quite easy to write such a thing in Go, and useful for assigning preferred timezone conversions, and colors for your special common log items.

Same dude that made jiff. Love that library, so I'm assuming biff is built on top of jiff.

also made ripgrep

And xsv. Burntsushi projects have certain quiet sensibility that I appreciate.

I only recently realized that xsv is now unmaintained. The author now suggests using qsv or xan.

So this is who I get to "blame" for LLMs constantly saying "I want to use `rg` but I see that it's not installed on this system...".

ripgrep is a required dependency of codex when installing it via brew on macOS. So you should at least not see it if you fall into that scenario. :-)

If you've got enough permissions on the device to install a local llm, go ahead and install rg. After a few decades of installing my pet toys on every *nix box I maintain, I've seriously scaled back. Yet I continue to install rg. I can think of only two other non-default Debian install tools that I use regularly, those are git and ncdu.

I misread the title as biff, and thought it was a back to the future reference. Turns out I need glasses AND it was a back to the future reference

This is a really great project. I plan on utilizing this in a function call for my preferred AI agent. Congratulations on this launch.

cargo-binstall support would be nice. https://github.com/cargo-bins/cargo-binstall/blob/main/SUPPO...

% biff

2026 M05 28, Thu 17:27:46

Ahh, the month of M05

just between a04 and j06 yes

Looking forward to the J07 04 holiday

This is a fair critique actually. And this shouldn't be the default. It is for now because I haven't gotten around to making Biff read your POSIX locale settings and converting them to a Unicode locale. If you build with `cargo build --release --features locale` (or get Biff from a release binary), then you can do:

    $ BIFF_LOCALE=en-US biff
    Thu, May 28, 2026, 6:38:09 AM EDT

If that doesn't work, then you can enable logging to see an error message:

    $ BIFF_LOCALE=watwat BIFF_LOG=warn biff
    2026-05-28T06:39:08.876336708-04:00[America/New_York]|WARN|src/main.rs:76: reading `BIFF_LOCALE` failed, using unknown locale `und`: failed to parse `BIFF_LOCALE` environment variable: The given language subtag is invalid
    2026 M05 28, Thu 06:39:08

What you're seeing is what ICU4X does when the user's locale is unknown or undetermined. The `M` prefix occurs to indicate that the number is the month, and is unrelated to the name. For example:

    $ BIFF_LOCALE=watwat biff time fmt -f '%c' '1 month'
    2026 M06 28, Sun 06:39:50

I came here to complain about this. Please read `LANG` like everything else :)

Oh yes definitely. Was always the plan. I was honestly just hoping someone would publish a crate to do that for me.

To be clear, I don't mean publishing a crate to read an environment variable. Of course. I mean a crate that converts a POSIX locale into a Unicode locale.

I guess there's probably a 20% solution that gets 80% of the way there. e.g.,

    $ BTTF_LOCALE="$(echo $LANG | sed 's/_/-/' | sed 's/\..*//')" bttf
    Thu, May 28, 2026, 11:46:21 AM EDT

If Biff just did that as a stop-gap until the full solution lands, I bet it would work in lots of cases.

No, Biff informs the system whether you want to be notified when mail arrives during the current terminal session.

Yes I'm sure root is anxious to read all the mail in their local mailbox

Sending mail to root@<whatever> really did use to be a pretty reliable way of getting somebody useful's attention - the early-to-mid 90s equivalent of making a "Can someone from Google please unlock my account?" post on HN.

Under Debian/Ubuntu, when Postfix is installed, part of the standard list of questions that dpkg-reconfigure asks you is how you want mail flow to work: you can give it a central smarthost. So any local mail gets sent on, and on the central mail hub you can tell it to send root@ to someplace useful:

* https://wiki.debian.org/Postfix#Forward_Emails

exactly. and chromium is a good looking space shooter with too few levels!

I.e.,

    NAME
       biff -- be notified if mail arrives and who it is from
    
    […]
    
    HISTORY
       The biff command appeared in 4.0BSD.  It was named  after  the  dog  of
       Heidi Stettner. He died in August 1993, at 15.

* https://man.freebsd.org/cgi/man.cgi?query=biff

    Eric Cooper, a student contemporary to Foderero and 
    Stettner, reports that the dog would bark at the mail 
    carrier,[4][5] making it a natural choice for the name 
    of a mail notification system. Stettner herself 
    contradicts this.[3][6]

* https://en.wikipedia.org/wiki/Biff_(Unix)

Also: <https://manpages.debian.org/stable/biff/biff.1.en.html>

From the excellent "A Quarter Century of UNIX" (by the late Peter H. Salus):

Heidi would bring her dog with her to class and to her office. He was a very friendly dog, and a lot of the students enjoyed throwing a ball for him down the corridor to fetch. He even had his picture on the bulletin board with the graduate students: the legend read that he was working on his Ph.Dog. John decided to name the program after the dog: Biff. According to Heidi, John and Bill Joy then spent a lot of time trying to compose an explanation for biff - they came up with "Be notified if mail arrived." Biff, who died in August 1993, at 15, once got a B in a compiler class. According to Heidi, the story of Biff barking at the mailman is a scurrilous canard.

One of my favourite bits of trivia from that excellent book, but hardly anyone I bump into these days knows anything about that kind of multi-user Unix experience/environment these days. I barely caught any of it myself.

Yeah this was before my time. I never did email from a terminal. Which probably explains why I was okay with naming it Biff.

In any case, I've renamed the project to bttf: https://github.com/BurntSushi/bttf/pull/14

I dont think it's part of the unix standard. Biff sounds perfect

My decisions about naming aren't limited or prescribed by what is in a standard or not. :-)

Thank you for helping maintain the Unix lore.

Yeah the name collision is unfortunate, but probably fine. The name Biff was just too good to pass up.

The name comes from the fact that Biff is a character in Back to the Future, and it rhymes with Jiff[1]. Jiff is the datetime library that Biff uses.

"Make like a tree and get out of here!" https://www.youtube.com/shorts/9Jabplo2pZU

[1]: https://github.com/BurntSushi/jiff

> Yeah the name collision is unfortunate, but probably fine. The name Biff was just too good to pass up.

So if I do an "apt install biff" on Debian (or Ubuntu) what will happen?

* https://packages.debian.org/search?keywords=biff

If I type in "biff" on a Debian CLI, what should I expect the behaviour of the program that is executed to be? Will it be something about mail or time?

I honestly don't know. Which is... Not Great.

I know that if you want `fd` (https://github.com/sharkdp/fd) you need to `apt install fd-find` and which installs the binary `fdfind` (!).

Per Debian policy and precedence of the email notification utility, you'll install biff, the command-line email notification utility:

<https://www.debian.org/doc/debian-policy/ch-binary.html#the-...>

<https://packages.debian.org/trixie/biff>

It was a great opportunity to name a unix tool "mcfly" or just "Marty" for time manipulation. Better luck next time, I guess.

That's... not terrible. Biff isn't exactly popular (yet?), so a name change isn't out of the question. Both of those names (and `biff`) are already taken on crates.io. Which is maybe not a huge problem. IDK. Naming is hard.

https://crates.io/search?q=bttf

// backronym bttf stands for biff time to format

I like this

also: back to the future

Burntsushi to the future

Intersting to notice that the name has been changed now when reading the post 12h late :-D

This is the fastest rebranding after a Show HN I think I’ve seen haha

You win the naming contest. The project has been renamed: https://github.com/BurntSushi/bttf/pull/14

@dang - Could you update the post title please to say "bttf" instead of "Biff"? Thank you!

I don't think @ tags have any effect on HN, you'll want to email the mods directly: hn@ycombinator.com

Naming is hard, sure, but doing some due diligence up front to see what's already being used isn't very difficult. Very neat tool.

I did. I always do. I just missed this one. Or if I saw it, it didn't register for me and felt like it was just an old archaic tool. Which... is probably still true, but I under-estimated its mindshare. Just an honest unknown unknown.

docbrown would be more appropriate, as the character who's actually doing the time manipulation.

Griff is still available for future projects or Buford if you create a throwback project.

> Yeah the name collision is unfortunate, but probably fine.

collisions, lol

  % apt-cache search biff
  biff - a mail notification tool
  gnubiff - mail notification program for GNOME (and others)
  wmbiff - Dockable app that displays information about mailboxes
  xlbiff - mail notification pop-up with configurable message scans

(along with 9 more matches without biff in command name)

Those are:

1. Not precise name collisions.

2. All mail-notification utilities, as was the original biff.

And since we're mentioning Debian, it has a policy requiring unique names within the Debian archive to be unique. Precedence goes to the earlier software packaged. Installed programs must also have unique names within a given system. The datetime Swiss army knife utility discussed here violates both policies.

As Debian policy is used both for Debian and derived distros (see: <https://en.wikipedia.org/wiki/List_of_Linux_distributions#De...> for a partial listing), it has considerable influence.

I've renamed the project to bttf :-)

That works on Debian ;-)

<https://packages.debian.org/search?keywords=bttf>

Might want to ping the mods (hn@ycombinator.com) to update this submission title.

Edit: I'd typoed "bttf" as "btff" initially. Corrected shows partial but not exact matches on "libttfautohint1" and variants.

As the author of a different project also named Biff, I do have to warn you that half the comments on your HN posts will be people quoting back to the future--though I haven't decided yet if that's annoying or an engagement hack!

[1] https://github.com/jacobobryant/biff

Back to the Future jokes never get old. I love it.

I still want one of those hover boards!

hellooo short-shorts

https://preview.redd.it/75ojrs5mzfcg1.jpeg?width=1024&auto=w...

B1FF IS LIMITED TO 22 COLUMNZ

All short names, that is, pronounceable strings of 4 or maybe even 5 letters are already taken. Some of them taken many times over.

I think fewer people now care about mail notifications in a terminal session than about wrangling datetimes on the command line.

For those confused by this and a few similar threads/comments: the project name was originally "biff", but that was changed apparently due to the discussion on this submission, which has been retitled.

The thing Biff gets right that gnu `date` and most stdlib datetime APIs get wrong: it treats "civil time" and "absolute instants" as different types. You cannot answer "what's 30 days from 2024-03-08 in America/New_York" without picking a side — DST means that's either 29d23h or 30d0h of elapsed time, and most APIs silently pick one without telling you.

Jiff (the underlying Rust crate) gets this from Temporal in TC39, which is the first time JS standards have led anything datetime-shaped. Hopefully the rest of the ecosystem catches up — Python's `zoneinfo` only landed in 3.9 and `datetime.timezone` still has sharp edges.

That's an interesting perspective because if I use America/New_York I would assume that it's subject to the laws of New York City. If I wanted a different DST regime I'd just use +4, +5, or a different city.

That's a complaint against how time zones are themselves named and organized. See https://ftp.iana.org/tz/tzdb-2022b/theory.html for all the gory details.

Using +4 or +5 explicitly instead of a time zone when DST is relevant is bad juju. Then your arithmetic can become silently wrong in subtle ways when it cross a DST boundary.

Ah I see, I didn't understand the original question properly. "Choose one side of DST or another" was meant for the time literal, not the TZ. That's my bad.

been hand-rolling date -d plus a wrapper script for newsletter scheduling for years. Stuff like "next second Tuesday after a holiday" and "convert these timestamps to a reader's local time before send". biff time seq monthly -w 2-tue would have replaced about 40 lines of bash for me.

Yes!!! To spell it out (with the new biff -> bttf name):

    $ bttf time seq monthly -w 2-tue -u 1y | bttf time fmt -f '%c'
    Tue, Jun 9, 2026, 11:15:11 AM EDT
    Tue, Jul 14, 2026, 11:15:11 AM EDT
    Tue, Aug 11, 2026, 11:15:11 AM EDT
    Tue, Sep 8, 2026, 11:15:11 AM EDT
    Tue, Oct 13, 2026, 11:15:11 AM EDT
    Tue, Nov 10, 2026, 11:15:11 AM EST
    Tue, Dec 8, 2026, 11:15:11 AM EST
    Tue, Jan 12, 2027, 11:15:11 AM EST
    Tue, Feb 9, 2027, 11:15:11 AM EST
    Tue, Mar 9, 2027, 11:15:11 AM EST
    Tue, Apr 13, 2027, 11:15:11 AM EDT
    Tue, May 11, 2027, 11:15:11 AM EDT

More examples here: https://github.com/BurntSushi/biff/blob/master/GUIDE.md#date...

Implementing the RFC 5545 recurrence rules was quite a lot of fun: https://github.com/BurntSushi/biff/blob/4c75d5cf6e09310e74ca...

I'm quite proud of it, because if you look at the implementation, it's almost entirely about dealing with the specification rules. All of the datetime bullshit (including handling time zones) is all deferred to Jiff.

Plus, the tests are nearly 4,000 lines. While the implementation is 2,000 lines.

I implemented those recursion rules (probably very poorly) years ago. I still often think about the ways I did and probably should have handled those. It was an interesting problem.

Looks great but I just can't see myself using a specialised tool and language for this. I think it's just easier to use ChatGPT or whatever for those one-offs, especially converting timestamps from a log.

I feel like this kind of tool has been completely obsoleted by LLMs (even local models). I've used similar tools such as tiny for Emacs, which is a DSL for generating text based on numeric ranges. Now, it's simply more efficient to ask AI.

Quite plausible. I built most of it in May 2025 (1 year ago) before I even looked at LLMs for coding, and announced it in Oct 2025[1]. I started it principally as a mechanism to dog-food Jiff[2]. Jiff has not been obsoleted by LLMs and is exactly the sort of thing an LLM would add as a dependency to a Rust project. This ended up being an extremely useful exercise because it did lead to some Jiff improvements.

Fun fact: ripgrep started as something to dog-food the regex crate (with a focus on performance). I didn't originally build it to release to end users funnily enough. To be clear, I'm not implying bttf will follow the same path. I honestly probably agree with you at this point. I wouldn't have 1 year ago though.

[1]: https://news.ycombinator.com/item?id=45608547

[2]: https://github.com/BurntSushi/jiff

I believe AI-for-everything will become unsustainable financially for many and I’m genuinely curious to see how people deal with it. When to use it? When is it wasteful?

My big hypothesis is that tokens are going to get much more expensive. Either that or OpenAI/anthropic are going bankrupt. I’m almost excited to find out, I have to admit.

Your remark just reminded me of this, I went a bit off topic, I admit.

Have you tried DeepSeek V4 Flash? It's very competent and extremely cheap.

I think Gemma 4 is also a good example of a capable small model.

I mention these not only because they're cheap but because they can run on consumer devices. The "every year bigger and more capable SOTA model" trend is mirrored by "the every year smaller and more capable open source model" trend.

256GB is what deepseek v4 flash with Q4 requires I believe. It is really still very far from “running locally on your device”. And it’s getting further away every day, looking at how the electronic market prices are surging.

I need to find stats on average RAM of personal devices, but I expect it will be so low, we are light years away from running a frontier model (from today) locally on a smartphone, let’s stop dreaming (and I really would love having it).

I do agree local models are progressing and I am to this day in awe at what a 50GB file can do – it still feels like black magic to me.

Also granted, something like Gemma 2 2B seems to have similar performance to ChatGP 3.5 and only require 2GB of RAM. But I think the RAM/performance ratio curve over time is logarithmic and not linear, it’s moving slower and slower.

Won't the most efficient LLMs just learn about and use tools like this, instead of crunching all the tokens to do it themselves?

Not really. Similarly to humans, it's easier to write code than read it; LLMs aren't particularly less efficient at doing off the cuff tasks vs reading in all of the tokens of documentation for a specific tool (assuming you did the legwork of manually feeding that tool to the LLM, which makes it less efficient for you) and then coming up with a solution. And that argument would only apply if there were custom tools for each of the infinite possible tasks, which there aren't.

Reply on news.ycombinator.com