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
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.
Under the "Countries Visited" section it says "been lucky to run on all seven continents, including antarctica!", but it doesn't look like they've been to Australia.
Oh lol you’re right! Perhaps they ran in Australia before they started this ten-year streak? In that case it could still be true, but not show in the data
Edit: also, they pulled the data from strava. It’s possible they forgot to record their Australian run(s) in strava for some reason
Notably not on the tectonic plate Australia is on (which is mostly although not entirely just Australia in terms of land), though, if someone is going by that definition.
Answering for myself, I started looking into APL, but at the time, learning the keymaps for the symbols seemed difficult, so I started learning array lang techniques with J, and ended up liking it.
Some of the knowledge you acquire from one array lang can translate to the others, but the semantics are not 1:1 (ie. J is not just ASCII APL).
As it currently stands, I dabble in almost all the array langs, but of the ones I use, I think best in J. It's got a lot of convenience in it's large set of primitives, and there's no "indirection" between the character you want, and the one you type. Still, it's not without it's shortcomings.
I think I would probably still recommend BQN to most people looking to get into array programming, as it removes some warts in APL/J.
You lose some convenience functions (base conversion, fixed-point, etc) but you get a language which is more uniform and intuitive. And FWIW, I had the keymaps learned within the first day I started to play with it.
It's still a learning curve regardless of which lang you learn, but it will change how you think.
Another Unicode article that mentions Swift, but not Raku :(
Raku's Str type has a `.chars` method that counts graphemes. It has a separate `.codes` method to count codepoints. It also can do O(1) string indexing at the grapheme level.
That Zalgo "word" example is counted as 4 chars, and the different comparisons of "Å" are all True in Raku.
You can argue about the merits of it's approach (indeed several commenters here disagree that graphemes are the "one true way" to count characters), but it feels lacking to not at least _mention_ Raku when talking about how different programming languages handle Unicode.
http://strangelyconsistent.org/blog/train-tracks