Hacker News

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

aftbit 8 hours ago [ - ]

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

burntsushi 7 hours ago [ - ]

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.