@anchrd/intel-ui 0.12.0 → 0.14.0

package/src/timezone/timezone-context.tsx

@@ -0,0 +1,45 @@
+import { createContext, type ReactNode, useContext, useMemo, useState } from "react";
+import { browserTimezone, readTimezone, rememberTimezone } from "./timezone.ts";
+
+// The React seam of the timezone preference, the same shape as i18n-context and theme-context.
+
+export interface TimezoneSelection {
+  current: string;
+  select(zone: string): void;
+}
+
+const TimezoneContext = createContext<TimezoneSelection | null>(null);
+
+interface TimezoneProviderProps {
+  store?: Pick<Storage, "getItem" | "setItem">;
+  children: ReactNode;
+}
+
+export function TimezoneProvider({ store, children }: TimezoneProviderProps) {
+  const [current, setCurrent] = useState(() => readTimezone(store));
+
+  const selection = useMemo<TimezoneSelection>(
+    () => ({
+      current,
+      select: (zone) => {
+        rememberTimezone(zone, store);
+        setCurrent(zone);
+      },
+    }),
+    [current, store],
+  );
+
+  return <TimezoneContext value={selection}>{children}</TimezoneContext>;
+}
+
+// `null` without a provider — the settings dialog asks whether there is anything to choose.
+export function useTimezoneSelection(): TimezoneSelection | null {
+  return useContext(TimezoneContext);
+}
+
+// The zone to read times in. Never null: a component without a provider still has to format a date,
+// and the browser's own zone is the honest answer there.
+export function useTimezone(): string {
+  const selection = useContext(TimezoneContext);
+  return selection?.current ?? browserTimezone();
+}

package/src/timezone/timezone.ts

@@ -0,0 +1,159 @@
+// The reader's timezone. Next to `intel.language` and `intel.theme`: the same kind of preference,
+// the same place.
+//
+// ⚠️ This is a preference, NOT the truth about when an agent fires. A schedule carries its own
+// timezone (#228); this value is the suggestion when one is created and the lens the calendar is
+// read through. The difference matters the day somebody travels: "08:00 Europe/Berlin" must stay
+// Berlin, and it would not if the schedule took whatever the reader's browser says today.
+const STORE_KEY = "intel.timezone";
+
+// What the browser thinks. Used when nothing was ever chosen — deliberately not "UTC": a default
+// nobody lives in is a default that produces schedules nobody meant.
+export function browserTimezone(): string {
+  try {
+    return Intl.DateTimeFormat().resolvedOptions().timeZone || "UTC";
+  } catch {
+    return "UTC";
+  }
+}
+
+// Every IANA name this runtime knows, for the picker. An engine without `supportedValuesOf` (or one
+// built without full ICU) yields the empty list, and the caller falls back to offering just the
+// browser's own zone — one real choice beats a picker that throws.
+export function availableTimezones(): string[] {
+  try {
+    return Intl.supportedValuesOf("timeZone");
+  } catch {
+    return [];
+  }
+}
+
+// Whether this runtime can actually format in that zone. The check is the formatting itself: a name
+// the engine rejects throws a RangeError here rather than in the middle of a calendar.
+export function isKnownTimezone(zone: string): boolean {
+  try {
+    new Intl.DateTimeFormat("en-US", { timeZone: zone });
+    return true;
+  } catch {
+    return false;
+  }
+}
+
+// A stored zone the engine no longer knows is discarded rather than kept: IANA renames zones, and a
+// name that stopped resolving would otherwise throw on every date the calendar draws.
+export function readTimezone(store?: Pick<Storage, "getItem">): string {
+  let stored: string | null = null;
+  try {
+    stored = store?.getItem(STORE_KEY) ?? null;
+  } catch {
+    return browserTimezone();
+  }
+  return stored !== null && isKnownTimezone(stored) ? stored : browserTimezone();
+}
+
+export function rememberTimezone(zone: string, store?: Pick<Storage, "setItem">): void {
+  try {
+    store?.setItem(STORE_KEY, zone);
+  } catch {
+    // A preference that cannot be written is still a preference for this session.
+  }
+}
+
+/** One zone as the picker shows it. Everything here is derived, nothing is stored. */
+export interface TimezoneOption {
+  zone: string;
+  /** "GMT+02:00", "GMT-04:00", "GMT" — present for every zone, which is why it carries the column. */
+  offsetLabel: string;
+  /** "MESZ", "JST" … or null where the runtime only repeats the offset. */
+  abbreviation: string | null;
+  /** Minutes east of UTC at `at`, for sorting. */
+  offsetMinutes: number;
+  /** What the search matches on, lowercased. */
+  keywords: string[];
+}
+
+function part(zone: string, style: "short" | "longOffset", at: Date, locale: string): string {
+  try {
+    return (
+      new Intl.DateTimeFormat(locale, { timeZone: zone, timeZoneName: style })
+        .formatToParts(at)
+        .find((piece) => piece.type === "timeZoneName")?.value ?? ""
+    );
+  } catch {
+    return "";
+  }
+}
+
+// "GMT+02:00" → 120, "GMT-04:00" → -240, "GMT" → 0. Read from the same string the label shows, so
+// the sort order and the text can never tell different stories.
+function minutesFrom(offsetLabel: string): number {
+  const match = /^GMT([+-])(\d{2}):(\d{2})$/.exec(offsetLabel);
+  if (!match) return 0;
+  const [, sign, hours, minutes] = match;
+  const total = Number(hours) * 60 + Number(minutes);
+  return sign === "-" ? -total : total;
+}
+
+/**
+ * The label of one zone, at a given moment.
+ *
+ * ⚠️ Computed at display time and never stored. A zone's offset AND its abbreviation move with
+ * daylight saving — Berlin is MEZ/+01:00 in January and MESZ/+02:00 in July — so a label written
+ * into a field would be wrong for half of every year.
+ *
+ * ⚠️ The abbreviation is dropped where `Intl` only echoes the offset — and WHICH zones have one
+ * depends on the READER'S LANGUAGE, not on the zone. CLDR ships short names only where a locale has
+ * its own word for that zone: a German reader gets "MEZ/MESZ" for Berlin and a bare "GMT-4" for New
+ * York; an English reader gets "EST/EDT" for New York and a bare "GMT+2" for Berlin. That is the
+ * useful way round — you get the abbreviation for the zones your language actually names — but it
+ * means this function's output is not the same in two languages, and a test has to say which one it
+ * is asserting. `Asia/Kolkata` has none in either ("GMT+5:30"), which is the common case worldwide.
+ */
+export function timezoneOption(zone: string, at: Date, locale: string): TimezoneOption {
+  const offsetLabel = part(zone, "longOffset", at, locale) || "GMT";
+  const short = part(zone, "short", at, locale);
+  // Dropped when it repeats the offset, and also when it repeats the zone's own name: "UTC" would
+  // otherwise render as "GMT · UTC   UTC", which stutters without adding anything.
+  const abbreviation =
+    short && !short.startsWith("GMT") && short !== offsetLabel && short !== zone ? short : null;
+  const city = zone.split("/").pop()?.replace(/_/g, " ") ?? zone;
+  return {
+    zone,
+    offsetLabel,
+    abbreviation,
+    offsetMinutes: minutesFrom(offsetLabel),
+    // The offset appears twice on purpose: as written ("GMT+02:00") and as typed ("+2"), because
+    // nobody searches for the leading zero.
+    keywords: [zone, city, offsetLabel, abbreviation ?? "", shorthandOffset(offsetLabel)]
+      .filter(Boolean)
+      .map((word) => word.toLowerCase()),
+  };
+}
+
+// "GMT+02:00" → "+2", "GMT+05:30" → "+5:30", "GMT" → "+0". What a person types.
+function shorthandOffset(offsetLabel: string): string {
+  const match = /^GMT([+-])(\d{2}):(\d{2})$/.exec(offsetLabel);
+  if (!match) return "+0";
+  const [, sign, hours, minutes] = match;
+  return `${sign}${Number(hours)}${minutes === "00" ? "" : `:${minutes}`}`;
+}
+
+/**
+ * Every selectable zone, sorted west to east.
+ *
+ * ⚠️ `current` is folded in even when `supportedValuesOf` does not list it. That is not a corner
+ * case: the list holds only CANONICAL names, and "UTC" is not one of them (it is an alias of
+ * Etc/UTC) — so the zone every CI machine and many servers report would otherwise be missing from
+ * the picker that is supposed to be showing it.
+ */
+export function timezoneOptions(current: string, at: Date, locale: string): TimezoneOption[] {
+  const zones = availableTimezones();
+  const all = zones.includes(current) ? zones : [current, ...zones];
+  return all
+    .map((zone) => timezoneOption(zone, at, locale))
+    .sort((left, right) =>
+      left.offsetMinutes === right.offsetMinutes
+        ? left.zone.localeCompare(right.zone)
+        : left.offsetMinutes - right.offsetMinutes,
+    );
+}

package/src/tools/tools.tsx

@@ -6,6 +6,7 @@ import * as React from "react";
 import { Button } from "@/components/ui/button";
 import { Collapsible, CollapsibleContent, CollapsibleTrigger } from "@/components/ui/collapsible";
 import type { I18n } from "@/i18n/i18n.types.ts";
+import { useI18n } from "@/i18n/i18n-context.tsx";
 import { useIntelRouterContext } from "@/router/router-context.ts";
 import { selectedFrom } from "@/router/selection-search.ts";
 
@@ -80,7 +81,8 @@ function attemptStore(): Storage | null {
 // The catalog is one live `tools/list` with the signed-in user's own portal token. Nothing here is
 // stored, mirrored or administered — the screen shows what the portal answers and nothing else.
 export function Tools() {
-  const { data, i18n } = useIntelRouterContext();
+  const { data } = useIntelRouterContext();
+  const i18n = useI18n();
   const catalog = useQuery({ queryKey: ["tools"], queryFn: () => data.listTools() });
   // The servers behind that same live list (D30). Its own query, and its own failure: a portal that
   // answers tools but no directory still has a usable screen, it just has no boxes to put them in.