@oneuptime/common 14.0.0 → 14.0.2

package/UI/Components/Feed/useFeedItems.ts

@@ -25,6 +25,14 @@ export interface FeedPage<TFeedModel> {
 
 export interface UseFeedItemsProps<TFeedModel> {
   resourceKey: string;
+  /*
+   * What the reader has chosen to see of this resource's feed - its sort
+   * order and event type filter (see useFeedOptions). A change re-reads the
+   * feed from its first window, exactly like moving to another resource:
+   * rows already loaded were read for the old view, so keeping them, or the
+   * size of the window they filled, would mix two different feeds.
+   */
+  viewKey?: string | undefined;
   refreshToken?: number | undefined;
   getItems: (limit: number) => Promise<FeedPage<TFeedModel>>;
   mapItems: (items: Array<TFeedModel>) => Array<FeedItemProps>;
@@ -50,7 +58,8 @@ interface FetchOptions {
 
 /*
  * Every dashboard activity feed follows the same paging contract: read the
- * newest top N rows and replace that window when the reader asks for more.
+ * first N rows in the reader's chosen order (newest first unless they asked
+ * for oldest first) and replace that window when the reader asks for more.
  * Re-reading from zero matters for a live feed. Offset-appending can duplicate
  * or skip a row when a new event arrives between page requests.
  */
@@ -71,10 +80,20 @@ const useFeedItems: <TFeedModel>(
     null,
   );
 
-  const activeResourceKeyRef: MutableRefObject<string> = useRef<string>(
-    props.resourceKey,
-  );
-  activeResourceKeyRef.current = props.resourceKey;
+  /*
+   * The resource and the view together name the feed being shown. Everything
+   * below that guards against a stale response or resets the window keys on
+   * this, so a response for the previous view is dropped the same way as a
+   * response for the previous resource.
+   */
+  const feedKey: string =
+    props.viewKey === undefined
+      ? props.resourceKey
+      : `${props.resourceKey}\u0000${props.viewKey}`;
+
+  const activeResourceKeyRef: MutableRefObject<string> =
+    useRef<string>(feedKey);
+  activeResourceKeyRef.current = feedKey;
   const previousResourceKeyRef: MutableRefObject<string | null> = useRef<
     string | null
   >(null);
@@ -184,8 +203,8 @@ const useFeedItems: <TFeedModel>(
 
   useEffect(() => {
     const hasResourceChanged: boolean =
-      previousResourceKeyRef.current !== props.resourceKey;
-    previousResourceKeyRef.current = props.resourceKey;
+      previousResourceKeyRef.current !== feedKey;
+    previousResourceKeyRef.current = feedKey;
 
     if (hasResourceChanged) {
       currentLimitRef.current = DEFAULT_LIMIT;
@@ -200,7 +219,7 @@ const useFeedItems: <TFeedModel>(
     }).catch(() => {
       // fetchItems converts request failures into the appropriate UI state.
     });
-  }, [fetchItems, props.resourceKey, props.refreshToken]);
+  }, [fetchItems, feedKey, props.refreshToken]);
 
   useEffect(() => {
     return () => {
@@ -208,7 +227,7 @@ const useFeedItems: <TFeedModel>(
     };
   }, []);
 
-  const isCurrentFeedLoaded: boolean = loadedResourceKey === props.resourceKey;
+  const isCurrentFeedLoaded: boolean = loadedResourceKey === feedKey;
 
   return {
     feedItems,

package/UI/Components/Feed/useFeedOptions.ts

@@ -0,0 +1,225 @@
+import {
+  MutableRefObject,
+  useCallback,
+  useEffect,
+  useMemo,
+  useRef,
+  useState,
+} from "react";
+import SortOrder from "../../../Types/BaseDatabase/SortOrder";
+import LocalStorage from "../../Utils/LocalStorage";
+import {
+  DEFAULT_FEED_SORT_ORDER,
+  FeedEventTypeOption,
+  FeedOptions,
+  GetFeedEventTypeIconFunction,
+  GetFeedEventTypeLabelFunction,
+  getFeedEventTypeOptions,
+  getFeedOptionsKey,
+  isFeedFiltered,
+  isFeedSortOrder,
+  sanitizeFeedEventTypes,
+} from "./FeedOptions";
+
+export interface UseFeedOptionsProps {
+  // Every event type the feed model can record, e.g. Object.values(the enum).
+  eventTypes: Array<string>;
+  getEventTypeLabel?: GetFeedEventTypeLabelFunction | undefined;
+  getEventTypeIcon?: GetFeedEventTypeIconFunction | undefined;
+  /*
+   * Names this kind of feed ("incident", "monitor", ...) so the reader's sort
+   * order is remembered across pages and visits. The event type filter is
+   * deliberately not remembered: it narrows one investigation, and a filter
+   * that silently followed the reader to the next incident would read as a
+   * feed with missing events.
+   */
+  storageKey?: string | undefined;
+  /*
+   * The resource whose feed this is (the incident id, the cluster id, ...).
+   * The dashboard moves between resources without remounting the feed, and
+   * the event type filter belongs to the resource it was chosen on, so a new
+   * resource starts unfiltered. The sort order is a preference and stays.
+   */
+  resetKey?: string | undefined;
+}
+
+export interface UseFeedOptionsResult {
+  options: FeedOptions;
+  // Pass to useFeedItems as viewKey: a change re-reads the feed.
+  optionsKey: string;
+  eventTypeOptions: Array<FeedEventTypeOption>;
+  isFiltered: boolean;
+  setOptions: (options: FeedOptions) => void;
+}
+
+const SORT_ORDER_STORAGE_KEY_PREFIX: string = "feed-sort-order:";
+
+// One shared empty selection, so an unfiltered render keeps its identity.
+const NO_EVENT_TYPES: Array<string> = [];
+
+type GetSortOrderStorageKey = (storageKey: string) => string;
+
+export const getSortOrderStorageKey: GetSortOrderStorageKey = (
+  storageKey: string,
+): string => {
+  return `${SORT_ORDER_STORAGE_KEY_PREFIX}${storageKey}`;
+};
+
+type ReadStoredSortOrder = (storageKey: string | undefined) => SortOrder;
+
+/*
+ * Storage can be missing, blocked or hold anything, so every read falls back
+ * to the default order.
+ */
+const readStoredSortOrder: ReadStoredSortOrder = (
+  storageKey: string | undefined,
+): SortOrder => {
+  if (!storageKey) {
+    return DEFAULT_FEED_SORT_ORDER;
+  }
+
+  try {
+    const storedValue: unknown = LocalStorage.getItem(
+      getSortOrderStorageKey(storageKey),
+    );
+
+    return isFeedSortOrder(storedValue) ? storedValue : DEFAULT_FEED_SORT_ORDER;
+  } catch {
+    return DEFAULT_FEED_SORT_ORDER;
+  }
+};
+
+type WriteStoredSortOrder = (
+  storageKey: string | undefined,
+  sortOrder: SortOrder,
+) => void;
+
+const writeStoredSortOrder: WriteStoredSortOrder = (
+  storageKey: string | undefined,
+  sortOrder: SortOrder,
+): void => {
+  if (!storageKey) {
+    return;
+  }
+
+  try {
+    if (sortOrder === DEFAULT_FEED_SORT_ORDER) {
+      LocalStorage.removeItem(getSortOrderStorageKey(storageKey));
+    } else {
+      LocalStorage.setItem(getSortOrderStorageKey(storageKey), sortOrder);
+    }
+  } catch {
+    // A preference that cannot be saved still applies to this page.
+  }
+};
+
+const useFeedOptions: (props: UseFeedOptionsProps) => UseFeedOptionsResult = (
+  props: UseFeedOptionsProps,
+): UseFeedOptionsResult => {
+  /*
+   * Callers pass Object.values(SomeEnum), a new array on every render, so the
+   * list is keyed by its contents.
+   */
+  const eventTypesKey: string = props.eventTypes.join("\u0000");
+  const knownEventTypes: Array<string> = useMemo(() => {
+    return props.eventTypes;
+  }, [eventTypesKey]);
+
+  const [sortOrder, setSortOrder] = useState<SortOrder>(() => {
+    return readStoredSortOrder(props.storageKey);
+  });
+  /*
+   * The selection remembers which resource it was made on. It is read through
+   * that, during render rather than in an effect, so the first render for a
+   * new resource is already unfiltered and never asks the API for the old
+   * resource's filter. The stale selection is also dropped (React's "adjust
+   * state when a prop changes" pattern), so going back to the first resource
+   * does not bring its old filter back either.
+   */
+  const [selection, setSelection] = useState<{
+    resetKey: string | undefined;
+    eventTypes: Array<string>;
+  }>(() => {
+    return {
+      resetKey: props.resetKey,
+      eventTypes: [],
+    };
+  });
+  const isSelectionForThisResource: boolean =
+    selection.resetKey === props.resetKey;
+
+  if (!isSelectionForThisResource) {
+    setSelection({
+      resetKey: props.resetKey,
+      eventTypes: NO_EVENT_TYPES,
+    });
+  }
+
+  const selectedEventTypes: Array<string> = isSelectionForThisResource
+    ? selection.eventTypes
+    : NO_EVENT_TYPES;
+
+  const options: FeedOptions = useMemo(() => {
+    return {
+      sortOrder,
+      eventTypes: sanitizeFeedEventTypes({
+        selectedEventTypes,
+        knownEventTypes,
+      }),
+    };
+  }, [sortOrder, selectedEventTypes, knownEventTypes]);
+
+  const eventTypeOptions: Array<FeedEventTypeOption> = useMemo(() => {
+    return getFeedEventTypeOptions({
+      eventTypes: knownEventTypes,
+      getEventTypeLabel: props.getEventTypeLabel,
+      getEventTypeIcon: props.getEventTypeIcon,
+    });
+  }, [knownEventTypes, props.getEventTypeLabel, props.getEventTypeIcon]);
+
+  const setOptions: (nextOptions: FeedOptions) => void = useCallback(
+    (nextOptions: FeedOptions): void => {
+      const nextSortOrder: SortOrder = isFeedSortOrder(nextOptions.sortOrder)
+        ? nextOptions.sortOrder
+        : DEFAULT_FEED_SORT_ORDER;
+
+      setSortOrder(nextSortOrder);
+      setSelection({
+        resetKey: props.resetKey,
+        eventTypes: sanitizeFeedEventTypes({
+          selectedEventTypes: nextOptions.eventTypes,
+          knownEventTypes,
+        }),
+      });
+    },
+    [knownEventTypes, props.resetKey],
+  );
+
+  /*
+   * The stored order follows the committed state, not each setOptions call:
+   * two changes batched into one render would otherwise leave storage holding
+   * the first while the page shows the second. The first run is the value
+   * just read from storage, so there is nothing to write.
+   */
+  const hasCommittedSortOrderRef: MutableRefObject<boolean> =
+    useRef<boolean>(false);
+
+  useEffect(() => {
+    if (!hasCommittedSortOrderRef.current) {
+      hasCommittedSortOrderRef.current = true;
+      return;
+    }
+
+    writeStoredSortOrder(props.storageKey, sortOrder);
+  }, [sortOrder]);
+
+  return {
+    options,
+    optionsKey: getFeedOptionsKey(options),
+    eventTypeOptions,
+    isFiltered: isFeedFiltered(options),
+    setOptions,
+  };
+};
+
+export default useFeedOptions;

package/UI/Components/Forms/Fields/FormField.tsx

@@ -43,6 +43,14 @@ import MarkdownEditor from "../../Markdown.tsx/MarkdownEditor";
 import YamlEditor from "../../CodeEditor/YamlEditor";
 import useTranslateValue from "../../../Utils/Translation";
 
+/*
+ * Shown under every DateTime and Time field. It is one sentence with
+ * placeholders, so a translator can put the zone wherever their language
+ * needs it, and the key is the same whichever zone the user is in.
+ */
+export const TIMEZONE_DESCRIPTION_TEMPLATE: string =
+  "This is in your timezone - {{abbreviation}} ({{timezone}}).";
+
 export interface ComponentProps<T extends GenericObject> {
   field: Field<T>;
   fieldName: string;
@@ -63,7 +71,7 @@ const FormField: <T extends GenericObject>(
 ) => ReactElement = <T extends GenericObject>(
   props: ComponentProps<T>,
 ): ReactElement => {
-  const { translateString } = useTranslateValue();
+  const { translateString, translateValue } = useTranslateValue();
   const translatedPlaceholder: string | undefined = translateString(
     props.field.placeholder,
   );
@@ -288,23 +296,48 @@ const FormField: <T extends GenericObject>(
       props.field.fieldType === FormFieldSchemaType.DateTime ||
       props.field.fieldType === FormFieldSchemaType.Time
     ) {
-      if (!fieldDescription) {
-        fieldDescription = "";
-      }
-
       /*
        * Name the zone in full. The abbreviation on its own ("EDT") is not
        * enough to tell whether the field is following the timezone picked in
        * User Settings or the one the browser reports.
        */
+      const timezoneValues: Dictionary<string> = {
+        abbreviation: OneUptimeDate.getCurrentTimezoneString(),
+        timezone: OneUptimeDate.getCurrentTimezone().toString(),
+      };
+
+      /*
+       * The description and the timezone sentence are looked up on their own.
+       * Joined first, the zone in the text kept the whole string from ever
+       * matching a locale entry, so both stayed in English. The sentence is
+       * looked up with its placeholders still in it and filled in here, which
+       * also works where no i18next instance is ready to interpolate.
+       */
+      const translatedDescription: string | ReactElement | undefined =
+        translateValue(props.field.description);
+
+      const timezoneSentence: string = (
+        translateString(TIMEZONE_DESCRIPTION_TEMPLATE) ||
+        TIMEZONE_DESCRIPTION_TEMPLATE
+      ).replace(
+        /\{\{(\w+)\}\}/g,
+        (placeholder: string, name: string): string => {
+          return timezoneValues[name] ?? placeholder;
+        },
+      );
+
+      /*
+       * Already translated, so it reaches FieldLabel as an element: FieldLabel
+       * looks string descriptions up again, and a translated sentence is not a
+       * key.
+       */
       fieldDescription = (
-        fieldDescription +
-        " This is in your timezone - " +
-        OneUptimeDate.getCurrentTimezoneString() +
-        " (" +
-        OneUptimeDate.getCurrentTimezone().toString() +
-        ")."
-      ).trim();
+        <>
+          {translatedDescription}
+          {translatedDescription ? " " : null}
+          {timezoneSentence}
+        </>
+      );
     }
 
     type GetFieldDescriptionFunction = () => ReactElement | string;
@@ -875,8 +908,10 @@ const FormField: <T extends GenericObject>(
           {props.field.fieldType === FormFieldSchemaType.Checkbox && (
             <CheckboxElement
               error={props.touched && props.error ? props.error : undefined}
-              title={props.field.title || ""}
-              description={props.field.description || ""}
+              title={
+                translateString(props.field.title) ?? props.field.title ?? ""
+              }
+              description={translateValue(props.field.description) || ""}
               onChange={async (value: boolean) => {
                 onChange(value);
                 props.setFieldValue(props.fieldName, value);

package/UI/Components/Graphs/DayUptimeGraph.tsx

@@ -6,7 +6,9 @@ import OneUptimeDate from "../../../Types/Date";
 import Dictionary from "../../../Types/Dictionary";
 import ObjectID from "../../../Types/ObjectID";
 import UptimeBarTooltipIncident from "../../../Types/Monitor/UptimeBarTooltipIncident";
-import DayUptimeGraphUtil from "../../../Utils/Uptime/DayUptimeGraphUtil";
+import DayUptimeGraphUtil, {
+  UptimeGraphDay,
+} from "../../../Utils/Uptime/DayUptimeGraphUtil";
 import UptimeHistoryLabels from "../../../Types/Monitor/UptimeHistoryLabels";
 import React, {
   FunctionComponent,
@@ -78,13 +80,20 @@ export interface ComponentProps {
   endDate: Date;
   events: Array<Event>;
   /*
-   * Server-measured coverage per day. When a day has a reading, it decides
-   * whether that day has data and what its durations are; the `events` array
-   * is then only used for incident overlays. When absent - the dashboard
-   * monitor page, which does not fetch the aggregate - the old event-derived
-   * behaviour applies unchanged.
+   * Server-measured coverage per day. When a day has a reading with coverage,
+   * it is the account of that day: whether the day has data, its percentage,
+   * its colour and its durations (see getUptimeBar). The events are not
+   * consulted for such a day. When absent, the old event-derived behaviour
+   * applies unchanged.
    */
   dayReadings?: Array<DayReading> | undefined;
+  /*
+   * The zone whose calendar days the bars stand for. Defaults to the
+   * browser's own. A caller passing dayReadings must pass the zone the
+   * readings were bucketed in - see DayUptimeGraphUtil.getDays - or each bar
+   * is paired with a reading for a different span of time.
+   */
+  timezone?: string | undefined;
   height?: number | undefined;
   barColorRules?: Array<BarChartRule> | undefined;
   downtimeEventStatusIds?: Array<ObjectID> | undefined;
@@ -105,15 +114,74 @@ export interface ComponentProps {
   labels?: UptimeHistoryLabels | undefined;
 }
 
+type GetReadingBarColorFunction = (
+  statusDurations: Array<StatusDuration>,
+  defaultBarColor: Color,
+) => Color;
+
+/*
+ * The colour of a day painted from the server's reading alone.
+ *
+ * The events path paints a day in the colour of its highest-priority status,
+ * so this does the same with the reading's durations. A status the day spent
+ * no time in cannot win, and two statuses at the same priority go to the one
+ * the day spent longer in. A caller that did not say what its statuses'
+ * priorities are still gets its worst time shown: the downtime status the
+ * day spent longest in, and only a day with no downtime at all gets the
+ * operator's colour.
+ */
+const getReadingBarColor: GetReadingBarColorFunction = (
+  statusDurations: Array<StatusDuration>,
+  defaultBarColor: Color,
+): Color => {
+  let highestPriority: StatusDuration | null = null;
+
+  for (const duration of statusDurations) {
+    if (duration.seconds <= 0 || typeof duration.priority !== "number") {
+      continue;
+    }
+
+    if (
+      !highestPriority ||
+      duration.priority > (highestPriority.priority as number) ||
+      (duration.priority === highestPriority.priority &&
+        duration.seconds > highestPriority.seconds)
+    ) {
+      highestPriority = duration;
+    }
+  }
+
+  if (highestPriority) {
+    return highestPriority.color;
+  }
+
+  let longestDowntime: StatusDuration | null = null;
+
+  for (const duration of statusDurations) {
+    if (!duration.isDowntime || duration.seconds <= 0) {
+      continue;
+    }
+
+    if (!longestDowntime || duration.seconds > longestDowntime.seconds) {
+      longestDowntime = duration;
+    }
+  }
+
+  return longestDowntime ? longestDowntime.color : defaultBarColor;
+};
+
 const DayUptimeGraph: FunctionComponent<ComponentProps> = (
   props: ComponentProps,
 ): ReactElement => {
-  const days: number = useMemo(() => {
-    return OneUptimeDate.getNumberOfDaysBetweenDatesInclusive(
-      props.startDate,
-      props.endDate,
-    );
-  }, [props.startDate, props.endDate]);
+  const graphDays: Array<UptimeGraphDay> = useMemo(() => {
+    return DayUptimeGraphUtil.getDays({
+      startDate: props.startDate,
+      endDate: props.endDate,
+      timezone: props.timezone,
+    });
+  }, [props.startDate, props.endDate, props.timezone]);
+
+  const days: number = graphDays.length;
 
   /*
    * The strip is one tab stop with a roving tabindex inside it - see
@@ -207,13 +275,11 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
   ): ReactElement => {
     let color: Color = props.defaultBarColor || Green;
 
-    const todaysDay: Date = OneUptimeDate.getSomeDaysAfterDate(
-      props.startDate,
-      dayNumber,
-    );
+    const graphDay: UptimeGraphDay = graphDays[dayNumber]!;
 
-    const startOfTheDay: Date = OneUptimeDate.getStartOfDay(todaysDay);
-    const endOfTheDay: Date = OneUptimeDate.getEndOfDay(todaysDay);
+    const todaysDay: Date = graphDay.date;
+    const startOfTheDay: Date = graphDay.startOfDay;
+    const endOfTheDay: Date = graphDay.endOfDay;
 
     /*
      * The server's reading for this day, when the caller supplied one. It is
@@ -330,6 +396,78 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
       }
     }
 
+    /*
+     * Whether the server's reading, rather than the events, decides this
+     * day's percentage and colour.
+     *
+     * Whenever it has one to give. The events the browser holds arrive under
+     * a fetch cap that silently drops history, and "the day still has some
+     * events" does not mean it has all of them:
+     *
+     *   - A day whose rows were ALL dropped has no events, and was painted
+     *     the operator's default colour at 100% - a day spent offline read as
+     *     a perfect one. On a page whose default colour is grey, every such
+     *     day was a grey bar next to a monitor that was up.
+     *
+     *   - The day the cap cuts through keeps only its newest rows, so its
+     *     percentage was taken over the few hours that survived.
+     *
+     *   - Today's rows were the newest of all, but the open row that carries
+     *     the current status still went missing: rows that started within
+     *     the same second were left in the server's newest-first order, so it
+     *     ended before it began (see UptimeUtil.compareTimelinesChronologically).
+     *     Today then had no events and was painted grey as well.
+     *
+     * The reading is measured server-side from every row, so for any day it
+     * covers it is the better account. It used to decide only days with no
+     * events at all; that left the two partial cases above wrong. A reading
+     * with no durations says nothing about how the day was spent, so it keeps
+     * the old treatment below.
+     */
+    const readingDecidesTheDay: boolean = Boolean(
+      todaysReading &&
+        todaysReading.coveredSeconds > 0 &&
+        todaysReading.statusDurations.length > 0,
+    );
+
+    if (readingDecidesTheDay && todaysReading) {
+      /*
+       * Downtime is the time spent in a status the caller counts as down, over
+       * the seconds the server actually covered. A duration carries no status
+       * id, so its isDowntime flag is the caller's answer, set from the same
+       * downtime statuses it passes as downtimeEventStatusIds. Clamped, so a
+       * reading whose durations overrun its coverage reads as a fully down
+       * day rather than as a negative uptime.
+       */
+      const downtimeInReading: number = todaysReading.statusDurations.reduce(
+        (sum: number, duration: StatusDuration) => {
+          return duration.isDowntime
+            ? sum + Math.max(duration.seconds, 0)
+            : sum;
+        },
+        0,
+      );
+
+      totalDowntimeInSeconds = Math.min(
+        downtimeInReading,
+        todaysReading.coveredSeconds,
+      );
+      totalUptimeInSeconds =
+        todaysReading.coveredSeconds - totalDowntimeInSeconds;
+
+      /*
+       * With bar rules, the rules below choose the colour from the reading's
+       * percentage, and a day no rule matches keeps the default colour, as
+       * it does on the events path.
+       */
+      if (!props.barColorRules || props.barColorRules.length === 0) {
+        color = getReadingBarColor(
+          todaysReading.statusDurations,
+          props.defaultBarColor || Green,
+        );
+      }
+    }
+
     /*
      * Does this day have data at all?
      *
@@ -391,14 +529,16 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
      * the fetch cap had thrown away.
      *
      * Now the two are separated. A day with data but no events of its own is
-     * an ordinary good day and still gets the operator's colour. A day with
-     * no data gets the fixed no-data treatment and says so.
+     * an ordinary good day and still gets the operator's colour, unless the
+     * server's reading says how the day was spent, in which case the colour
+     * chosen from that reading above stands. A day with no data gets the
+     * fixed no-data treatment and says so.
      */
     hasEvents = hasDataForTheDay;
 
     if (!hasDataForTheDay) {
       color = NO_DATA_BAR_COLOR;
-    } else if (todaysEvents.length === 0) {
+    } else if (todaysEvents.length === 0 && !readingDecidesTheDay) {
       color = props.defaultBarColor || Green;
     }
 
@@ -452,10 +592,10 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
     };
 
     const ariaLabel: string = DayUptimeGraphUtil.getDayAriaLabel({
-      dateLabel: OneUptimeDate.getDateAsUserFriendlyLocalFormattedString(
-        todaysDay,
-        true,
-      ),
+      dateLabel: DayUptimeGraphUtil.formatDayLabel({
+        date: todaysDay,
+        timezone: props.timezone,
+      }),
       hasEvents: hasEvents,
       uptimePercent: uptimePercentForTheDay,
       incidentCount: dayIncidents.length,
@@ -469,6 +609,7 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
         richContent={
           <UptimeBarTooltip
             date={todaysDay}
+            timezone={props.timezone}
             uptimePercent={uptimePercentForTheDay}
             hasEvents={hasEvents}
             statusDurations={statusDurations}

package/UI/Components/Graphs/UptimeBarTooltip.tsx

@@ -1,4 +1,5 @@
 import OneUptimeDate from "../../../Types/Date";
+import DayUptimeGraphUtil from "../../../Utils/Uptime/DayUptimeGraphUtil";
 import UptimeBarTooltipIncident from "../../../Types/Monitor/UptimeBarTooltipIncident";
 import UptimeDaySummary, { StatusDuration } from "./UptimeDaySummary";
 import UptimeHistoryLabels, {
@@ -22,13 +23,20 @@ export interface ComponentProps {
   onIncidentClick?: ((incidentId: string) => void) | undefined;
   /* Defaults to English. The status page passes translated strings. */
   labels?: UptimeHistoryLabels | undefined;
+  /*
+   * The zone the bar's day was drawn in, so the date reads as that day. The
+   * browser's own zone when absent. See DayUptimeGraphUtil.formatDayLabel.
+   */
+  timezone?: string | undefined;
 }
 
 const UptimeBarTooltip: FunctionComponent<ComponentProps> = (
   props: ComponentProps,
 ): ReactElement => {
-  const dateStr: string =
-    OneUptimeDate.getDateAsUserFriendlyLocalFormattedString(props.date, true);
+  const dateStr: string = DayUptimeGraphUtil.formatDayLabel({
+    date: props.date,
+    timezone: props.timezone,
+  });
 
   const hasIncidents: boolean = props.incidents.length > 0;
   const labels: UptimeHistoryLabels =