Prompt y contexto
Un sistema de reservas global recibe “New York time 2026-11-01 01:30” y muestra y notifica a los participantes en sus propias zonas. Usando JavaScript Temporal, diseña el parseo, la vinculación de zona, la persistencia y la visualización mientras manejas horas locales inexistentes o repetidas durante las transiciones del horario de verano. No colapses la semántica de fecha, hora y zona en una sola cadena o en un objeto Date.
Lo que el entrevistador está evaluando
Las señales son distinguir Temporal.Instant, Temporal.ZonedDateTime, Temporal.PlainDateTime y Temporal.PlainDate, comprender las reglas de IANA, la ambigüedad del horario de verano (DST), la precisión y la serialización. Las respuestas sólidas explican por qué una fecha del calendario de negocio no es automáticamente un instante UTC y cómo preservar el sistema de calendario.
Preguntas de clarificación para hacer primero
Semántica de entrada
Confirma si la entrada es una hora de reloj de pared en una zona con nombre o un instante ya resuelto, y si la zona proviene del evento, la organización o el navegador. Sin una zona, la hora local es ambigua.
Política de ambigüedad de DST
Pregunta si las horas inexistentes o repetidas deben rechazarse, elegir la anterior o posterior, o requerir confirmación. La política pertenece al contrato del producto, no a un valor predeterminado accidental del tiempo de ejecución.
Requisito de persistencia
Determina si un recordatorio es un instante absoluto único o se repite cada año en un calendario local. Una reserva única y una regla tipo cumpleaños requieren diferentes tipos de Temporal.
Marco de respuesta de 30 segundos
“Mantén la entrada del usuario como PlainDateTime más una zona IANA explícita, luego aplica la política del producto para crear ZonedDateTime y Instant. Persiste un Instant para un recordatorio único y conviértelo a la zona de cada espectador para la visualización. Persiste la fecha local, la hora, la zona y las reglas del calendario para eventos recurrentes. Rechaza o elige explícitamente una desambiguación de DST y preserva la semántica original; evita el parseo implícito de zona local de Date”.
Pasos detallados de la respuesta
Paso 1: Elegir el tipo correcto
PlainDate es una fecha del calendario sin zona, PlainDateTime es una fecha y hora de reloj de pared sin zona, ZonedDateTime vincula una zona IANA y Instant es un punto en la línea de tiempo. Selecciona el tipo a partir del significado de negocio primero.
Paso 2: Parsear y vincular la zona
Parsea la entrada del usuario en PlainDateTime, obtén un identificador de zona confiable y combínalos en ZonedDateTime. Nunca uses silenciosamente la zona predeterminada del navegador o del servidor como la zona del evento.
Paso 3: Manejar las transiciones de DST
El adelanto de hora en primavera crea horas locales inexistentes; el retraso de hora en otoño crea horas locales repetidas. Aplica una desambiguación explícita como rechazar y preguntar al usuario nuevamente, o elegir anterior/posterior cuando el requisito lo permita. Registra esa elección con la reserva.
Paso 4: Convertir al instante del recordatorio
Para una reserva única, obtén un Instant a partir de ZonedDateTime y persiste una cadena normalizada. Programa mediante el Instant; conviértelo a la zona del espectador solo al momento de la visualización en lugar de reinterpretar el texto original del reloj de pared.
Paso 5: Preservar la semántica de eventos recurrentes
Un evento anual a las 09:00 locales no se puede almacenar como un solo desplazamiento UTC porque el DST cambia ese desplazamiento. Persiste PlainDate, PlainTime, la zona IANA y el sistema de calendario, luego resuelve un nuevo ZonedDateTime para cada ocurrencia.
Paso 6: Definir precisión y calendario
Especifica si se requieren milisegundos, microsegundos o nanosegundos; no trunques durante la serialización ni rompas el ordenamiento. Para calendarios de negocio no ISO, persiste el identificador del calendario en lugar de tratar su fecha como una fecha ISO.
Paso 7: Probar límites
Cubre el adelanto de primavera y el retraso de otoño, límites de año, años bisiestos, actualizaciones de la base de datos de zonas horarias, diferencias de locale y viajes de ida y vuelta de serialización. Valida el instante, la visualización local y la regla de recurrencia por separado en lugar de comparar únicamente cadenas.
Respuesta de muestra de alta calidad
Parsearía la entrada como PlainDateTime, requeriría una zona IANA y aplicaría una política explícita de DST para crear ZonedDateTime. Persistiría Instant para recordatorios únicos y lo convertiría para cada espectador; persistiría la fecha local, la hora, la zona y las reglas del calendario para recurrencias y resolvería un nuevo instante cada vez. Las pruebas cubren horas inexistentes y repetidas, años bisiestos, actualizaciones de la base de datos de zonas y precisión. Esto evita el comportamiento de zona implícita de Date.
Errores comunes
- Error: Tratar
PlainDateTimecomo UTC. → Por qué: No tiene semántica de zona. → Mejora: Vincula primero una zona IANA explícita. - Error: Persistir solo un desplazamiento UTC para eventos anuales. → Por qué: El DST cambia el desplazamiento local. → Mejora: Persiste la hora local y las reglas de zona.
- Error: Ignorar la hora repetida del cambio de otoño. → Por qué: Una hora de pared mapea a dos instantes. → Mejora: Rechaza o elige explícitamente anterior/posterior.
- Error: Validar únicamente la igualdad de cadenas. → Por qué: Las cadenas no demuestran la semántica de instante o calendario. → Mejora: Valida el comportamiento de Instant, ZonedDateTime y recurrencia por separado.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cuándo se debe persistir un Instant?
Cuando el evento representa una ocurrencia absoluta en la línea de tiempo, como enviar un recordatorio o registrar un pago. La zona del espectador cambia la presentación, no el instante.
Pregunta de seguimiento 2: ¿Por qué un cumpleaños no debería almacenarse como un Instant?
Un cumpleaños es una fecha del calendario local, no usualmente un instante simultáneo a nivel global. Almacena la fecha, la zona y las reglas del calendario, y luego calcula un instante para cada ocurrencia.
Pregunta de seguimiento 3: ¿Puede una actualización de la base de datos de zonas horarias afectar a las reservas guardadas?
Sí. Las reglas futuras de la hora local pueden cambiar. Preserva la zona y la semántica originales, registra una versión de la regla cuando sea necesario y define cómo se maneja el recálculo.
Pregunta de seguimiento 4: ¿Temporal decide automáticamente la ambigüedad de DST?
La API ofrece opciones de desambiguación, pero el producto debe elegir entre rechazar, anterior, posterior o comportamiento compatible. Una opción predeterminada no es una política de negocio.