-
Notifications
You must be signed in to change notification settings - Fork 19.8k
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
- Clone apache/echarts,
npm install - Set system timezone to any DST-observing zone (e.g., America/New_York, Europe/Berlin, Australia/Sydney)
- Run
npm run test - Observe
roundTime_localetest failure intest/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.<anonymous> (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:
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 OctoberIn 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)