OWASP / OWASP/Nest

deadlineUtils.test.ts fails outside UTC timezones due to mixing local/UTC date components

Open Beginner friendly
#5,592 3 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
Python
Stars
451
Forks
707
Avg merge
22h 59m
Merged PRs (30d)
91

Description

**Describe the bug**
The test `"should ignore time component and only compare dates"` in
`frontend/__tests__/unit/utils/deadlineUtils.test.ts` (lines 80–101) constructs `earlyMorning` and `lateNight` using the local-time `Date` constructor, but passes it UTC date components:

```
const today = new Date()
const earlyMorning = new Date(
today.getUTCFullYear(),
today.getUTCMonth(),
today.getUTCDate(), // UTC date component...
0, 0, 0 // ...fed into a LOCAL-time constructor
)
```

**To Reproduce**
Steps to reproduce the behavior:

1. Set the system/CI timezone to something ahead of UTC, e.g. `TZ=Asia/Shanghai`
2. Run `cd frontend && pnpm run test:unit -- deadlineUtils`
3. See the test `"should ignore time component and only compare dates"` fail with `expected due-soon, received overdue`

Verified directly by extracting `getDeadlineCategory` and running it under different `TZ` settings:

| TZ | earlyMorning result | lateNight result |
|---|---|---|
| UTC | `due-soon` ✅ | `due-soon` ✅ |
| Asia/Shanghai (UTC+8) | `overdue` ❌ | `due-soon` ✅ |
| Pacific/Auckland (UTC+12/13) | `overdue` ❌ | `due-soon` ✅ |

**Expected behavior**
The test should pass regardless of the timezone it's run in. `earlyMorning` and `lateNight` should be constructed entirely with UTC methods (e.g. `Date.UTC(...)`, or `setUTCHours`/`setUTCMinutes`/`setUTCSeconds`) so their components stay consistent with the `toISOString()` output the function under test relies on.

**Are you going to work on fixing this?**

- [x] Yes
- [ ] No

**Screenshots**
If applicable, add screenshots to help explain your problem.

**Desktop (please complete the following information):**

- OS: [macOS]
- Browser [ safari]
- Version [26.6.2]

**Smartphone (please complete the following information):**

- Device: [e.g. iPhone6]
- OS: [e.g. iOS8.1]
- Browser [e.g. stock browser, safari]
- Version [e.g. 22]

**Additional context**
- Affected file: `frontend/__tests__/unit/utils/deadlineUtils.test.ts`, lines 80–101
- Source under test (`frontend/src/utils/deadlineUtils.ts`) is correct and needs no changes
- Suggested fix: replace the local-time `Date` constructor calls with `Date.UTC(...)`-based construction, e.g.:
```js
const earlyMorning = new Date(Date.UTC(
today.getUTCFullYear(), today.getUTCMonth(), today.getUTCDate(), 0, 0, 0
))
const lateNight = new Date(Date.UTC(
today.getUTCFullYear(), today.getUTCMonth(), today.getUTCDate(), 23, 59, 59
))
```

Contributor guide

Open the contributing guide

Research direction

Start with frontend/__tests__/unit/utils/deadlineUtils.test.ts lines 80–101 and compare its Date construction with the UTC-based behavior described in the issue. Run `cd frontend && pnpm run test:unit -- deadlineUtils` under `TZ=Asia/Shanghai` or another non-UTC timezone. Done means the named test passes consistently outside UTC without changing frontend/src/utils/deadlineUtils.ts.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend, testing
Issue type
Bug
Difficulty
1/5
Estimated time
Under an hour
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
88/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.