### System details

Tested on Kali Linux (x86_64), Omarchy quattro branch, commit 821ae589. Affected rule is distro-agnostic (sudo/regex evaluation, not Arch-specific), but worth confirming the same drop-in is generated identically on a stock Arch/Omarchy install.

### What's wrong?

Note: This report is submitted for awareness and to assist with fixing
a functionality defect. This is not a security vulnerability and
carries no security impact.

The sudoers rule installed for passwordless timezone updates rejects
essentially all real IANA timezone names due to a regex typo, forcing
the "set timezone without a password prompt" convenience path to fail
for normal usage.

Rule installed at /etc/sudoers.d/omarchy-tzupdate:

  zubiii ALL=(root) NOPASSWD: /usr/bin/timedatectl ^set-timezone [A-Za-z0-9_+][A-Za-z0-9_+.-](/[A-Za-z0-9_+][A-Za-z0-9_+.-])*$

Root cause: each path segment is built from two single-character classes
with no repetition quantifier on the second class, so every segment
(before and after each `/`) is forced to be exactly 2 characters long.
This rejects:

  - "UTC" (3 characters)
  - "America/New_York" (far more than 2 chars per segment)
  - basically every real timezone name

It's presumably missing a `*` on the second class, e.g.:

  ^set-timezone [A-Za-z0-9_+][A-Za-z0-9_+.-]*(/[A-Za-z0-9_+][A-Za-z0-9_+.-]*)*$

Steps to reproduce:

  $ sudo -n /usr/bin/timedatectl set-timezone "UTC"
  sudo: a password is required

  $ sudo -n /usr/bin/timedatectl set-timezone "America/New_York"
  sudo: a password is required

  $ sudo -n /usr/bin/timedatectl set-timezone "UT"
  Failed to set time zone: Invalid or not installed time zone 'UT'
  (passes the sudoers regex since it's exactly 2 chars, but isn't a
  real timezone — confirms the regex itself is the blocker, not
  timedatectl)

Scope/impact: this is a functionality bug only, not a security issue.
I specifically tested the opposite (permissive) failure direction —
command injection via `;`, embedded newlines, extra arguments — and
confirmed sudo correctly rejects all of those; the rule only fails in
the overly-restrictive direction. Reported here per the security
policy's own guidance that non-boundary-crossing robustness issues are
improvements rather than vulnerabilities, and are better handled as a
regular issue/PR.

Suggested fix: change the character classes to allow repetition, e.g.

  ^set-timezone [A-Za-z0-9_+][A-Za-z0-9_+.-]*(/[A-Za-z0-9_+][A-Za-z0-9_+.-]*)*$

matching whatever pattern is used for variable-length segments in
other Omarchy sudoers rules (e.g. omarchy-dns) for consistency. Happy
to open a PR with this fix if that's useful.

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/f91c9fd1-5e2e-4b50-87c6-5d95b1bac931" />

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/f82da941-08cb-4709-8346-be21432b7c38" />

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/5cced193-2eb4-41a7-a78a-b4cf54014a44" />

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/9090a1c7-c022-4da5-bfdb-c3beb1ed4b79" />

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/0d48bf5d-ff27-486a-802f-006c1aef9b2f" />