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.
  });
});