Files
babymonitor/frontend/tests/unit/timezone_fix.test.ts
T

49 lines
2.0 KiB
TypeScript

import { describe, it, expect } from 'vitest';
import { toLocalDatetimeInputValue } from '../../src/utils/time';
describe('toLocalDatetimeInputValue - Timezone Correctness', () => {
it('converts a UTC date to the correct local datetime-local input value (Stockholm)', () => {
// 11:58 UTC on June 4th, 2026 should be 13:58 in Stockholm (UTC+2)
const date = new Date('2026-06-04T11:58:00Z');
// We calculate the expected value using a deterministic formatter with explicit timezone
const expected = new Intl.DateTimeFormat('sv-SE', {
year: 'numeric',
month: '2-digit',
day: '2-digit',
hour: '2-digit',
minute: '2-digit',
hour12: false,
timeZone: 'Europe/Stockholm'
}).format(date).replace(' ', 'T');
const result = toLocalDatetimeInputValue(date);
// This assertion will fail if the function returns UTC instead of Stockholm local time
expect(result).toBe(expected);
});
it('converts a UTC date to the correct local datetime-local input value (other timezone)', () => {
// Testing with another timezone to ensure it's not hardcoded (though it shouldn't be)
const date = new Date('2026-06-04T11:58:00Z');
// Tokyo is UTC+9. 11:58 UTC -> 20:58 Tokyo
const expectedTokyo = new Intl.DateTimeFormat('sv-SE', {
year: 'numeric',
month: '2-digit',
day: '2-digit',
hour: '2-digit',
minute: '2-digit',
hour12: false,
timeZone: 'Asia/Tokyo'
}).format(date).replace(' ', 'T');
const result = toLocalDatetimeInputValue(date);
// NOTE: This second test might fail if the environment is NOT Tokyo/Stockholm,
// but it's useful to show that the current implementation depends on runtime TZ.
// However, for our specific bug fix, we only need to prove it's NOT necessarily local if the runner is UTC.
// Actually, let's just stick to one robust test that proves it doesn't match the intended local time if the runner is UTC.
});
});