analyze-timezone-sensitive-scheduling-boundaries
Public Insights analysis package for detecting likely timezone-sensitive scheduling and date boundary handling in JavaScript and TypeScript repositories.
This package is read-only. It does not rewrite source files. It scans JS/TS/TSX code and increments one Insights metric per finding.
What It Detects
The workflow records findings for these risky patterns:
new Date("YYYY-MM-DD")Date.parse(...)new Date()orDate.now()in scheduling/query boundary logic.toISOString()in scheduling/query boundary logictoLocaleString(),toLocaleDateString(), andtoLocaleTimeString()without explicittimeZoneoptions- ORM/query/filter boundary objects on
startTime,endTime,createdAt,updatedAt,start,end, andexpiresAt
The analysis boosts confidence when the file path or nearby code suggests scheduling-related domains such as booking, scheduling, slot, calendar, availability, appointment, attendee, event, meeting, or reservation.
Targeting And Exclusions
- Included:
**/*.{js,jsx,ts,tsx,mjs,cjs,mts,cts} - Excluded: tests, fixtures, mocks, snapshots, e2e, coverage, generated files, build output, and
node_modules
Metric
This package uses exactly one metric:
- Metric name:
timezone-sensitive-scheduling-boundary
Cardinality keys emitted on every increment:
kind:date-only-construction,date-parse,now-boundary,iso-boundary,locale-format,query-boundaryboundaryField:startTime,endTime,createdAt,updatedAt,start,end,expiresAt, orunknownconfidence:low,medium,highdomain:booking,scheduling,slot,calendar,availability,appointment,attendee,event,meeting,reservation, orgenerictimezoneContext:input.timeZone,user.timeZone,schedule.timeZone,teamTimeZone,orgTimeZone,calendarTimeZone,attendeeTimeZone,timeZone,timezone,tz, ornoneapi:new-date,date-parse,date-now,toISOString, orquery-filterfilename: basename of the analyzed file such asquery.ts,bookings.repository.ts, orAvailabilityTable.tsxlanguage:typescript,tsx, orjavascript
Workflow
- Workflow name:
main - Workflow step name:
analyze-timezone-boundaries
Example Insights metric source:
Example query grouped by kind:
Example query grouped by boundaryField:
Example query grouped by repository:
Example query grouped by filename:
Usage
Run locally:
Run tests:
Test Coverage
Fixtures cover these scenarios without modifying source output:
- no-op read-only behavior
new Date().toISOString()in astartTimequery boundarynew Date("YYYY-MM-DD")createdAtandupdatedAtrange filters- nearby timezone identifiers contributing
timezoneContext - nested file fixtures proving
filenameis emitted as a basename only - safe timezone validation/import code producing no edits and no intended findings
The JSSG fixture harness in this package validates both read-only behavior and metric output through metrics.json snapshots. Those fixtures now assert that the package still emits exactly one metric via useMetricAtom("timezone-sensitive-scheduling-boundary") and that each finding includes the basename-only filename cardinality.
License
MIT