[BUG] Tests fail in non-integer timezones (e.g., IST, ACST) due to local time assertions

[h30s]

Description

The test suite contains assertions that rely on Date.prototype.getMinutes() on locally created Date objects derived from UTC timestamps. This causes test failures in environments where the local timezone offset is not an integer number of hours (e.g., India Standard Time UTC+05:30, Australian Central Standard Time UTC+09:30).

When a cron schedule is set to run at a specific minute (e.g., 15 * * * * or "minute 15 of every hour"), the verification logic expects nextRunAt.getMinutes() to equal 15. However, in a timezone with a +30 minute offset (like IST), a time that is :15 in UTC will appear as :45 (or vice versa) in local time.

Reproduction Steps

I have verified this behavior by running the tests with explicit timezone environment variables:

1. Passing Condition (UTC or Integer Timezones):

   TZ=UTC bun run test apps/sim/app/api/schedules/[id]/route.test.ts

   Result: Tests pass.

2. Failing Condition (Non-integer Timezones):

   TZ=Asia/Kolkata bun run test apps/sim/app/api/schedules/[id]/route.test.ts

   Result: Tests fail.

FAIL  app/api/schedules/[id]/route.test.ts > Schedule PUT API (Reactivate) > Timezone Handling in Reactivation > handles hourly schedules with timezone correctly
AssertionError: expected 45 to be 15 // Object.is equality

Expected Behavior

Tests should pass deterministicly regardless of the machine's local timezone.

Actual Behavior

Tests fail with assertion errors on the minute value when the local timezone has a non-integer offset (e.g. +X:30 or +X:45).

Affected Files

• apps/sim/app/api/schedules/[id]/route.test.ts
• apps/sim/lib/workflows/schedules/utils.test.ts

Proposed Fix

Update the test assertions to use getUTCMinutes() instead of getMinutes() to verify against stable UTC calculations, avoiding the local system's offset interference.

Example change:

// Before
expect(nextRunAt.getMinutes()).toBe(15)

// After
expect(nextRunAt.getUTCMinutes()).toBe(15)