apache / apache/echarts

[Bug] roundTime_locale test fails in DST-observing timezones

Open
#21,538 0 comments 0 reactions 0 assignees View on GitHub
en pending
Dominant language
TypeScript
Stars
67.3k
Forks
19.8k
Avg merge
11d 14h
Merged PRs (30d)
8

Description

### Version

6.0.0 (bug present on current `master`)

### Link to Minimal Reproduction

N/A — this is a test-only bug. Run `npm run test` in any DST-observing timezone (US, EU, Australia, NZ, Brazil, etc.).

### Steps to Reproduce

1. Clone apache/echarts, `npm install`
2. Set system timezone to any DST-observing zone (e.g., America/New_York, Europe/Berlin, Australia/Sydney)
3. Run `npm run test`
4. Observe `roundTime_locale` test failure in `test/ut/spec/util/time.test.ts`

### Current Behavior

```
FAIL test/ut/spec/util/time.test.ts
● util/time › roundTime › roundTime_locale

expect(received).toEqual(expected) // deep equality

Expected: 528526800000
Received: 528523200000

at Object. (spec/util/time.test.ts:166:18)
```

The 3,600,000ms difference (exactly 1 hour) is the DST offset.

### Expected Behavior

All unit tests should pass regardless of the machine's timezone.

### Root Cause

The `getISOTimezone()` helper in `time.test.ts` computes the UTC offset from `new Date(0)` (January 1, 1970) and applies that fixed offset string to construct expected dates across different months:

```typescript
function getISOTimezone(): string {
const offsetMinutes = (new Date(0)).getTimezoneOffset(); // ← always January offset
// ...
}

// Then used for October dates:
new Date(\`1986-10-01T00:00:00.000\${timezoneStr}\`) // ← January offset applied to October
```

In DST-observing timezones, the offset in January differs from October. For example, US Eastern:
- January: UTC-5 (EST)
- October: UTC-4 (EDT)

So `getISOTimezone()` returns `-05:00`, but `new Date('1986-10-01T00:00:00.000-05:00')` constructs midnight EST, which is 1AM EDT. Meanwhile `roundTime()` correctly rounds to midnight local time (EDT), producing a 1-hour mismatch.

The `roundTime_UTC` test passes because it uses `.toISOString()` which is timezone-independent.

### Environment

- **OS:** Any (macOS, Linux, Windows)
- **Node:** 18+
- **Timezone:** Any DST-observing timezone (fails in ~70% of world timezones)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.