## System details

- Hardware: HP OMEN Laptop 15-en0xxx · AMD Ryzen 7 4800H · NVIDIA GeForce RTX 2060 Mobile
- Software: Omarchy 4.0.4-1 · kernel 7.2.5-3-omarchy · Hyprland 0.56.2 · quickshell 0.3.1-1
- Timezone: `America/Santiago` · Locale: `en_US.UTF-8`
- Debug log: `/tmp/omarchy-debug.log`

## What's wrong?

The calendar popup of the clock widget (`omarchy.clock`, `shell/plugins/panels/clock/`) **duplicates one day when the visible month crosses a forward DST transition**, which shifts every following row of the month grid by one day. The weekday names no longer match the day numbers (e.g. today's date lands under the wrong column).

**Steps to reproduce**

1. Set the timezone to a zone with a forward DST jump (e.g. `America/Santiago`; here the transition is Sat Sep 5 2026 24:00 → Sun Sep 6 01:00, so midnight Sep 6 does not exist).
2. Make sure September 2026 is the visible month (today is Sep 22, 2026 in that zone).
3. Click the clock in the top bar to open the calendar.

Observed grid (week start Sunday, locale default) — **5 is duplicated**, everything below is off by one:

```
30 31  1  2  3  4  5
 5  6  7  8  9 10 11   ← duplicate day, rest of the grid shifted
12 13 14 15 16 17 18
19 20 21 22 23 24 25   ← 22 (today, a Tuesday) sits under the "WED" column
26 27 28 29 30  1  2
 3  4  5  6  7  8  9
```

Expected grid:

```
30 31  1  2  3  4  5
 6  7  8  9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30  1  2  3
```

The bug is independent of week start — with `weekStartDay: monday` it also duplicates a day (in that case 5 appears twice inside row 1).

**Root cause**

`monthGrid()` in `shell/plugins/panels/clock/Model.js` builds the date cursor at **local midnight** and advances it with `cursor.setDate(cursor.getDate() + 1)`:

```js
var cursor = new Date(year, month, 1 - leading)
...
cursor.setDate(cursor.getDate() + 1)
```

The Qt QML JS engine (V4) mishandles the nonexistent local time when incrementing across a forward DST jump. Minimal repro, evaluated with `QJSEngine` under `America/Santiago`, tzdata 2026:

```js
var d = new Date(2026, 8, 5);   // Sat Sep 5 2026 00:00 -04
d.setDate(d.getDate() + 1);     // should be Sun Sep 6 01:00 -03
// V8 (Node): 2026-9-6 01:00  → getDate() === 6  ✓
// V4 (Qt QML): 2026-8-5 23:00 → getDate() === 5  ✗  (rolls back 1h, day repeats)
```

I verified the same `Model.js` produces the **correct** grid under Node (V8) and the **buggy** grid under Qt's QJSEngine (V4), and that a running shell renders the buggy one (screenshot below). The week-number column (`isoWeek`) is fine because it computes in UTC.

**Local workaround that fixes it (verified in V4)**

Build the cursor at **noon** instead of midnight, so the stored time-of-day exists in every timezone:

```js
var cursor = new Date(year, month, 1 - leading, 12)
```

After this one-line change the full month grid renders correctly at both week starts (second screenshot below). I applied it locally by cloning the plugin (`omarchy plugin clone omarchy.clock`) and editing `Model.js` — not touching `/usr/share/omarchy`.

**Suggested upstream fix**

Use a midday hour when constructing the grid cursor in `monthGrid()` (and audit the other local-midnight `new Date(year, month, day)` uses in the panel for the same class of bug, e.g. `new Date(year, month, 1)` for `leading`). A DST-safe alternative is to iterate on `Date.UTC`.

**Captures**

- `omarchy-bug-calendar-before.png` — buggy grid (5 duplicated, shifted rows)
- `omarchy-bug-calendar-after.png` — same view after the noon-cursor fix (rows continuous, correct alignment)

Both extracted straight from a screen capture of the live panel (this report was written without image uploads, so they are attached separately).