packages/ui/src/timestamp-tooltip.tsx (4)

102-106: “UNIX Timestamp” unit ambiguity (ms vs s).

date.getTime() returns milliseconds. Most users expect UNIX timestamps in seconds. Either divide by 1000 or rename the label.

Choose one:

• Prefer seconds:

- label: "UNIX Timestamp",
- value: date.getTime().toString(),
+ label: "UNIX (s)",
+ value: Math.floor(date.getTime() / 1000).toString(),

• Or keep ms but clarify:

- label: "UNIX Timestamp",
+ label: "UNIX (ms)",

---

15-17: className prop is unused.

className is accepted but never applied.

Pass it to a trigger wrapper without altering layout:

-    >
-      {children}
+    >
+      <span className={className}>{children}</span>
     </Tooltip>

If your Tooltip supports a trigger class prop, prefer that to avoid extra span.

Also applies to: 33-35, 115-171

---

120-140: Accessibility: clickable rows are not keyboard‑operable.

<tr> has onClick but no role/tabindex/keyboard handling. Screen‑reader and keyboard users can’t activate copy.

Make the row operable when interactive:

-              <tr
+              <tr
+                role={interactive ? "button" : undefined}
+                tabIndex={interactive ? 0 : -1}
                 key={idx}
                 className={cn(
                   interactive &&
                     "before:bg-bg-emphasis relative select-none before:absolute before:-inset-x-1 before:inset-y-0 before:rounded before:opacity-0 before:content-[''] hover:cursor-pointer hover:before:opacity-60 active:before:opacity-100",
                 )}
                 onClick={interactive ? /* ... */ : undefined}
+                onKeyDown={
+                  interactive
+                    ? (e) => {
+                        if (e.key === "Enter" || e.key === " ") {
+                          e.preventDefault();
+                          (e.currentTarget as HTMLElement).click();
+                        }
+                      }
+                    : undefined
+                }
               >

Optionally add focus styles (e.g., focus:outline focus:outline-2).

Also applies to: 141-160

---

52-74: Future timestamps show “… ago”.

If date > now, UI still appends “ago” (and diff logic includes seconds). Consider “in …” or “Just now” thresholds.

Example:

-  const relative =
-    formatDuration(relativeDuration, { ... }) + " ago";
+  const isFuture = date > new Date();
+  const relative =
+    formatDuration(relativeDuration, { ... }) + (isFuture ? "" : " ago");
+  if (isFuture) relative = `in ${relative}`;

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/commissions/commission-table.tsx (1)

93-101: LGTM! Good interactive timestamp tooltip usage.

The TimestampTooltip integration works well for the Date column. The interactive mode with all timestamp formats is appropriate for a financial data table where precise timestamps matter.

Minor suggestion: Consider adding select-none to the <p> tag for consistency with events-table.tsx (Line 194), which prevents text selection conflicts when users click to copy timestamps in interactive mode.

-              <p>{formatDateTimeSmart(row.original.createdAt)}</p>
+              <p className="select-none">{formatDateTimeSmart(row.original.createdAt)}</p>

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/bounties/[bountyId]/bounty-submissions-table.tsx (1)

189-203: Consider standardizing TimestampTooltip props for consistency.

The implementation is correct, but there's an inconsistency with the earnings-table.tsx usage:

• This file uses default props: rows defaults to ["local", "utc"] and interactive defaults to false
• earnings-table.tsx explicitly sets rows={["local"]} and interactive={true}

This creates an inconsistent user experience where some timestamps show both local and UTC times with click-to-copy, while others show both timezones without the ability to copy.

Consider standardizing the props across all TimestampTooltip instances. For example:

 <TimestampTooltip
   timestamp={row.original.createdAt}
   side="left"
+  rows={["local"]}
+  interactive
   delayDuration={150}
 >

Or alternatively, establish a project-wide convention for which props should be used in table timestamp columns and apply it consistently.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

packages/ui/src/timestamp-tooltip.tsx (1)

96-98: DST bug: timezone abbreviation derived from current time, not the row's timestamp.

Using new Date() here yields the current timezone abbreviation (e.g., "PDT" for Pacific Daylight Time) even if the date being displayed falls in a different DST period (e.g., "PST" for Pacific Standard Time). This causes the short label to mismatch the actual timestamp's timezone state.

Apply this fix to derive the abbreviation from the row's date:

- shortLabel: new Date()
-   .toLocaleTimeString("en-US", { timeZoneName: "short" })
-   .split(" ")[2],
+ shortLabel: Intl.DateTimeFormat("en-US", {
+   hour: "2-digit",
+   timeZoneName: "short",
+ })
+   .formatToParts(date)
+   .find((p) => p.type === "timeZoneName")?.value,

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

packages/ui/src/timestamp-tooltip.tsx (2)

107-109: DST bug still present: short timezone label uses current time instead of the timestamp.

As flagged in the previous review and confirmed by TWilson023, using new Date() yields the current timezone abbreviation (e.g., PDT) even if the timestamp is in a different DST period (e.g., PST).

The fix should derive the short label from the actual date variable:

-              shortLabel: new Date()
-                .toLocaleTimeString("en-US", { timeZoneName: "short" })
-                .split(" ")[2],
+              shortLabel: Intl.DateTimeFormat("en-US", { 
+                hour: "2-digit", 
+                timeZoneName: "short" 
+              })
+                .formatToParts(date)
+                .find((p) => p.type === "timeZoneName")?.value,

Based on learnings and previous review discussion.

---

72-93: Future timestamps and empty duration edge cases not handled.

The relative duration logic has two unresolved issues from the previous review:

1. Future timestamps: When date > now, diff becomes negative and intervalToDuration receives inverted start/end, producing incorrect results.
2. Empty duration: If formatDuration returns an empty string (timestamps very close together), the output becomes just " ago".

Apply this refactor to handle both cases:

+ const now = new Date();
+ const isPast = date.getTime() <= now.getTime();
+
- const diff = new Date().getTime() - date.getTime();
+ const diff = Math.abs(now.getTime() - date.getTime());
  const relativeDuration = intervalToDuration({
-   start: date,
-   end: new Date(),
+   start: isPast ? date : now,
+   end: isPast ? now : date,
  });
- const relative =
-   formatDuration(relativeDuration, {
+ const formattedDuration = formatDuration(relativeDuration, {
      delimiter: ", ",
      format: [
        "years",
        "months",
        "days",
        ...(diff < MONTH_MS
          ? [
              "hours" as const,
              ...(diff < DAY_MS
                ? ["minutes" as const, "seconds" as const]
                : []),
            ]
          : []),
      ],
-   }) + " ago";
+   });
+ const relative = formattedDuration
+   ? `${formattedDuration} ${isPast ? "ago" : "from now"}`
+   : "just now";

packages/ui/src/timestamp-tooltip.tsx (2)

57-58: Unreachable defensive throw creates confusing error contract.

The parent component (TimestampTooltip) already validates the timestamp at line 34, so this throw is unreachable in normal execution. If it somehow executes, throwing before hooks violates React's rules.

Remove the redundant check or replace it with a development-only assertion:

- if (!timestamp)
-   throw new Error("Falsy timestamp not permitted in TimestampTooltipContent");
+ if (process.env.NODE_ENV === "development" && !timestamp) {
+   console.error("TimestampTooltipContent received falsy timestamp");
+ }

---

134-139: Consider cleanup and performance implications of second-by-second re-renders.

Re-rendering every second is appropriate for keeping relative timestamps fresh, but consider:

1. When the tooltip is not visible, this still runs (minor performance concern)
2. Multiple tooltip instances on a page each have their own intervals

For optimization, consider using a global interval or visibility detection, though the current approach is acceptable for typical use cases.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

packages/ui/src/timestamp-tooltip.tsx (2)

72-93: Handle future timestamps and empty duration edge cases.

As flagged in previous reviews, this code doesn't handle:

1. Future timestamps: intervalToDuration expects start < end. For future dates, results are undefined or incorrect.
2. Zero-duration edge case: If formatDuration returns empty string (timestamp ≈ now), the display shows just " ago".

Apply this fix:

+ const now = new Date();
+ const isPast = date.getTime() <= now.getTime();
+ 
- const diff = new Date().getTime() - date.getTime();
+ const diff = Math.abs(now.getTime() - date.getTime());
  const relativeDuration = intervalToDuration({
-   start: date,
-   end: new Date(),
+   start: isPast ? date : now,
+   end: isPast ? now : date,
  });
- const relative =
-   formatDuration(relativeDuration, {
+ const formattedDuration = formatDuration(relativeDuration, {
      delimiter: ", ",
      format: [
        "years",
        "months",
        "days",
        ...(diff < MONTH_MS
          ? [
              "hours" as const,
              ...(diff < DAY_MS
                ? ["minutes" as const, "seconds" as const]
                : []),
            ]
          : []),
      ],
-   }) + " ago";
+   });
+ const relative = formattedDuration
+   ? `${formattedDuration} ${isPast ? "ago" : "from now"}`
+   : "just now";

---

108-110: Fix DST bug: short label uses current time instead of timestamp's date.

As flagged in previous reviews, line 108 uses new Date() (current time) to derive the timezone abbreviation. This returns the wrong abbreviation when the timestamp is in a different DST period (e.g., shows "PDT" for a winter timestamp that should be "PST").

Apply this fix to use the actual timestamp's date:

              label: getLocalTimeZone(),
-             shortLabel: new Date()
-               .toLocaleTimeString("en-US", { timeZoneName: "short" })
-               .split(" ")[2],
+             shortLabel: Intl.DateTimeFormat("en-US", { 
+               hour: "2-digit", 
+               timeZoneName: "short" 
+             })
+               .formatToParts(date)
+               .find((p) => p.type === "timeZoneName")?.value,
              successMessageLabel: "local timestamp",

This also eliminates the brittle string split.

apps/web/ui/customers/customer-table/customer-table.tsx (1)

175-186: Consider showing all timestamp formats for consistency.

This table uses rows={["local"]} while most other tables in this PR use rows={["local", "utc", "unix"]} (e.g., events-table.tsx line 191, link-creator-info.tsx line 33). Providing UTC and UNIX timestamps helps users working across timezones or with APIs.

Apply this diff for consistency:

           <TimestampTooltip
             timestamp={row.original.createdAt}
-            rows={["local"]}
+            rows={["local", "utc", "unix"]}
             side="left"
             delayDuration={150}
           >

apps/web/app/(ee)/partners.dub.co/(dashboard)/programs/[programSlug]/(enrolled)/earnings/earnings-table.tsx (1)

82-88: Consider including UTC and UNIX timestamps for consistency.

Like the customer table, this uses rows={["local"]} while most other tables show all three formats. Partners often work with API integrations where UTC/UNIX timestamps are valuable.

Apply this diff:

           <TimestampTooltip
             timestamp={row.original.createdAt}
             side="right"
-            rows={["local"]}
+            rows={["local", "utc", "unix"]}
           >

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro