[feat] : Add schedule types, enums, constants, and utilities#41
[feat] : Add schedule types, enums, constants, and utilities#41not-meet wants to merge 1 commit into
Conversation
| @@ -0,0 +1,14 @@ | |||
| export function daysBetween(sinceTimestamp: number): string[] { | |||
There was a problem hiding this comment.
nitpick: daysBetween ignores utcOffsetMinutes. Likely a bug for the eventual integration.
ScheduleDraft.utcOffsetMinutes signals that reports are anchored to the admin's local timezone, but daysBetween (src/lib/utils/scheduleSummaryUtils.ts) computes day boundaries purely in UTC (setUTCHours, toISOString().slice(0, 10)). When these are combined in a follow-up PR, a report period that spans a local-midnight boundary will bucket flags into the wrong calendar day near the edges.
Suggest reconciling now. For example: accept the offset as a parameter and shift before slicing the date. Or, for now, at minimum add a // UTC-only comment so the follow-up doesn't silently inherit the mismatch.
There was a problem hiding this comment.
hey @scuciatto ! , I Looked into this, and I believe we should not add the timezone offset into how flags are bucketed for storage. Here's why: the offset can change if someone updates the schedule later, maybe another admin with a different timezone, and if storage depends on it, old flags and new flags could end up filed inconsistently. Thus keeping one single independent source of truth for flag saving time looks more stable.
I did add one change in persistence to close a related gap: AdminActionLogStore.getActionsSince was returning the whole first day's bucket instead of cutting off exactly at the requested timestamp, fixed with a direct filter on the entry's timestamp (entry.timestamp >= sinceTimestamp), no timezone math needed.
Description
Adds the foundational types, enums, constants, language objects etc for
upcoming scheduled spam-report feature.