🤖 This pull request was created by Repo Assist, an automated AI assistant.

Summary

Fixes DateTimeOffset.ToString with format specifiers D, d, T, t, and custom format strings producing wrong date/time components when the runner or end-user machine is in a non-UTC timezone.

Closes #4375

Root Cause

dateToStringWithOffset in Date.ts constructed the offset-adjusted date with new Date(...), which produces a plain JavaScript Date with no kind property:

const d = new Date(date.getTime() + (date.offset ?? 0));

The helper functions day(), month(), year(), dayOfWeek(), hour(), etc. all branch on d.kind:

export function day(d: IDateTime) {
 return d.kind === DateTimeKind.Utc ? d.getUTCDate() : d.getDate();
}

When kind is undefined, they fall through to the local-timezone JS methods (.getDate(), .getMonth(), etc.). On a machine in e.g. Australia/Melbourne (UTC+10), a DateTimeOffset of 2014年09月01日T16:37:02+02:00 (UTC: 14:37:02 on Sep 1) produces an offset-adjusted timestamp of 2014年09月01日T16:37:02Z. But .getDate() in Melbourne returns September 2 (since it is past midnight local time).

Fix

Use the DateTime() factory with DateTimeKind.Utc instead of new Date():

const d = DateTime(date.getTime() + (date.offset ?? 0), DateTimeKind.Utc);

Since we have already added the stored offset to shift the UTC epoch to the "wall clock" time, reading via UTC getters (getUTCDate(), getUTCMonth(), etc.) gives the correct result regardless of local timezone.

Trade-offs

• Minimal, targeted change — only affects dateToStringWithOffset
• All format paths (D, d, T, t, O/o, custom) remain correct
• toUniversalTime(d) now returns d unchanged (already Utc kind), correct for T/t formatting
• dateToISOStringWithOffset accepts Date and IDateTime extends Date, TypeScript typing is satisfied

Generated by Repo Assist · ●くろまる 10.4M · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f