Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-4602GitHub issuePublicFixed

Bar clock always shows weekday/month names in English, ignoring system locale (LANG)

Reported by isaac30503 · filed Aug 15, 2026Closed upstream on 2026-08-15 by dhh, as not planned.

Received and recorded verbatim. Nothing has been checked yet.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
Not yet mapped to any requirement or component.
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

Bar clock always shows weekday/month names in English, ignoring system locale (LANG)revision 1 · captured 2026-10-04 12:03 UTC via poll

Title

Bar clock always shows weekday/month names in English, ignoring system locale (LANG)

Description

The bar clock widget (omarchy.clock) always renders weekday names (dddd/ddd) and month names (MMMM/MMM) in English, regardless of the system locale. Setting LANG/LC_TIME to a non-English locale (e.g. es_MX.UTF-8) correctly changes every other locale-aware value on the system, but the clock widget in the bar is unaffected.

This used to work correctly under the old waybar-based bar (pre-Quattro); it broke after the migration to the Quickshell-based omarchy-shell.

Steps to reproduce

  1. Set a non-English system locale, e.g.:
   localectl set-locale LANG=es_MX.UTF-8

and reboot.
2. Confirm the locale is applied system-wide:

   $ localectl status
   System Locale: LANG=es_MX.UTF-8
   $ systemctl --user show-environment | grep LANG
   LANG=es_MX.UTF-8
  1. Set the bar clock format to include a weekday/month token, e.g. dddd HH:mm (the default).
  2. Observe the bar: it shows Saturday 14:05 instead of the expected sábado 14:05.

Root cause

BarWidget.qml for the clock plugin formats the date with the QML global function Qt.formatDateTime(date, format):

https://github.com/basecamp/omarchy/blob/master/shell/plugins/panels/clock/BarWidget.qml

function formatted(date) {
  return Qt.formatDateTime(date, activeFormat.replace(/ww/g, Model.isoWeekLiteral(date.getFullYear(), date.getMonth(), date.getDate())))
}

The two-argument Qt.formatDateTime(date, format) overload does not use the application's default locale for textual tokens (dddd, ddd, MMMM, MMM) — it always formats those using English/C-locale names, independent of Qt.locale() or the process environment.

I confirmed this directly against the running quickshell binary (Quickshell 0.3.0) with LANG=es_MX.UTF-8 LC_ALL=es_MX.UTF-8:

Qt.locale().name:                         es_MX
Qt.formatDateTime(d, "dddd d MMMM"):      Saturday 15 August      ← wrong
d.toLocaleString(Qt.locale(), "dddd HH:mm"): sábado 14:05         ← correct

So Qt.locale() correctly resolves to es_MX (the system/env locale is picked up fine), but Qt.formatDateTime() simply doesn't consult it for weekday/month names. Date.prototype.toLocaleString(locale, format) (and toLocaleDateString/toLocaleTimeString), by contrast, do honor the passed-in QLocale and render the correct localized names, while still supporting the same format-token syntax (including the custom ww week-number substitution already done by Model.isoWeekLiteral).

Suggested fix

Swap the formatting call in formatted() to a locale-aware one:

function formatted(date) {
  return date.toLocaleString(Qt.locale(), activeFormat.replace(/ww/g, Model.isoWeekLiteral(date.getFullYear(), date.getMonth(), date.getDate())))
}

I applied exactly this one-line change locally and confirmed the bar clock now renders correctly in Spanish (sáb 15 ago 01:47 instead of Sat 15 Aug 01:47) after an omarchy-restart-shell. No other format tokens (vertical format, 'W'ww week literal, AM/PM) regressed in my testing.

I didn't find any other use of Qt.formatDateTime elsewhere in shell/, so this appears to be the only spot affected.

Environment

  • Omarchy: 4.0.0-1
  • quickshell-git: 0.3.0.r20.g28771c7-1
  • Hyprland: 0.56.2-1
  • Locale: LANG=es_MX.UTF-8
View raw text
## Title
Bar clock always shows weekday/month names in English, ignoring system locale (LANG)

## Description

The bar clock widget (`omarchy.clock`) always renders weekday names (`dddd`/`ddd`) and month names (`MMMM`/`MMM`) in English, regardless of the system locale. Setting `LANG`/`LC_TIME` to a non-English locale (e.g. `es_MX.UTF-8`) correctly changes every other locale-aware value on the system, but the clock widget in the bar is unaffected.

This used to work correctly under the old waybar-based bar (pre-Quattro); it broke after the migration to the Quickshell-based `omarchy-shell`.

## Steps to reproduce

1. Set a non-English system locale, e.g.:
   ```
   localectl set-locale LANG=es_MX.UTF-8
   ```
   and reboot.
2. Confirm the locale is applied system-wide:
   ```
   $ localectl status
   System Locale: LANG=es_MX.UTF-8
   $ systemctl --user show-environment | grep LANG
   LANG=es_MX.UTF-8
   ```
3. Set the bar clock format to include a weekday/month token, e.g. `dddd HH:mm` (the default).
4. Observe the bar: it shows `Saturday 14:05` instead of the expected `sábado 14:05`.

## Root cause

`BarWidget.qml` for the clock plugin formats the date with the QML global function `Qt.formatDateTime(date, format)`:

https://github.com/basecamp/omarchy/blob/master/shell/plugins/panels/clock/BarWidget.qml

```qml
function formatted(date) {
  return Qt.formatDateTime(date, activeFormat.replace(/ww/g, Model.isoWeekLiteral(date.getFullYear(), date.getMonth(), date.getDate())))
}
```

The two-argument `Qt.formatDateTime(date, format)` overload does **not** use the application's default locale for textual tokens (`dddd`, `ddd`, `MMMM`, `MMM`) — it always formats those using English/C-locale names, independent of `Qt.locale()` or the process environment.

I confirmed this directly against the running `quickshell` binary (`Quickshell 0.3.0`) with `LANG=es_MX.UTF-8 LC_ALL=es_MX.UTF-8`:

```
Qt.locale().name:                         es_MX
Qt.formatDateTime(d, "dddd d MMMM"):      Saturday 15 August      ← wrong
d.toLocaleString(Qt.locale(), "dddd HH:mm"): sábado 14:05         ← correct
```

So `Qt.locale()` correctly resolves to `es_MX` (the system/env locale is picked up fine), but `Qt.formatDateTime()` simply doesn't consult it for weekday/month names. `Date.prototype.toLocaleString(locale, format)` (and `toLocaleDateString`/`toLocaleTimeString`), by contrast, do honor the passed-in `QLocale` and render the correct localized names, while still supporting the same format-token syntax (including the custom `ww` week-number substitution already done by `Model.isoWeekLiteral`).

## Suggested fix

Swap the formatting call in `formatted()` to a locale-aware one:

```qml
function formatted(date) {
  return date.toLocaleString(Qt.locale(), activeFormat.replace(/ww/g, Model.isoWeekLiteral(date.getFullYear(), date.getMonth(), date.getDate())))
}
```

I applied exactly this one-line change locally and confirmed the bar clock now renders correctly in Spanish (`sáb 15 ago 01:47` instead of `Sat 15 Aug 01:47`) after an `omarchy-restart-shell`. No other format tokens (vertical format, `'W'ww` week literal, AM/PM) regressed in my testing.

I didn't find any other use of `Qt.formatDateTime` elsewhere in `shell/`, so this appears to be the only spot affected.

## Environment

- Omarchy: 4.0.0-1
- quickshell-git: 0.3.0.r20.g28771c7-1
- Hyprland: 0.56.2-1
- Locale: `LANG=es_MX.UTF-8`

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

  • Fixed bypr/7173· confirmed
  • Related PRpr/10776· confirmed
  • Related PRpr/13546· confirmed
  • Fixed bypr/13851· confirmed
  • Related PRpr/15117· confirmed

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

No decision has been recorded yet.