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.
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 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.
> 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.
> “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):
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)
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.
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.
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.
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.
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.
28 comments
[ 2.8 ms ] story [ 57.5 ms ] thread2026 M05 28, Thu 17:27:46
Ahh, the month of M05
[0]: https://www.fresse.org/dateutils/
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.
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):
Or even ask for a specific time window: 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.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.
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):
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!):> 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.
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