Métodos Get: Extraer Componentes de Fechas en JavaScript
Domina los métodos get para extraer año, mes, día, hora, minutos y segundos de objetos Date. Aprende la diferencia entre métodos locales y UTC.
TL;DR - Resumen rápido
- getDate() es el día del mes (1-31), getDay() es día de semana (0-6) - no confundirlos
- getMonth() devuelve 0-11, no 1-12: suma 1 antes de mostrar o usa array de nombres
- Métodos UTC son para almacenamiento/APIs, métodos locales para mostrar al usuario
- padStart(2, '0') convierte números a strings de dos dígitos (9 → '09') para formateo
- getTimezoneOffset() devuelve minutos, es positivo al oeste de UTC (contra-intuitivo)
Introducción a los Métodos Get
Los métodos get extraen componentes individuales de un objeto Date: año, mes, día, hora, minutos, segundos y milisegundos. A diferencia de lenguajes que tienen tipos separados para fecha y hora, JavaScript usa un solo objeto Date, por lo que estos métodos son tu única forma de acceder a componentes individuales. Entenderlos es esencial porque getMonth() devuelve 0-11 (no 1-12), getDay() devuelve día de semana (no día del mes), y estos errores causan bugs silenciosos.
JavaScript ofrece dos variantes de cada método: local (zona horaria del sistema) y UTC (tiempo universal). Esta dualidad es crítica: métodos locales varían según la configuración del usuario, causando inconsistencias en aplicaciones multi-zona. La regla de oro: usa UTC para almacenamiento y cálculos, local solo para mostrar al usuario. Mezclarlos es una fuente común de bugs de zona horaria difíciles de reproducir.
- getFullYear() y getUTCFullYear() para el año
- getMonth() y getUTCMonth() para el mes (0-11)
- getDate() y getUTCDate() para el día del mes (1-31)
- getHours(), getMinutes(), getSeconds() para el tiempo
- getDay() y getUTCDay() para el día de la semana (0-6)
Retorno numérico
Todos los métodos get devuelven números, no strings. Esto significa que getMonth() devuelve 0 para enero, no "enero". Si necesitas el nombre del mes, debes convertir el número usando un array o un objeto de mapeo.
Métodos para Extraer Componentes de Fecha
Los métodos básicos de fecha extraen año, mes y día. Aquí está el problema: getMonth() devuelve 0-11 (herencia de Java), mientras que getDate() devuelve 1-31. Esta inconsistencia causa el bug más común con fechas: mostrar "mes 0" al usuario o crear new Date(2025, 2, 1) pensando que es febrero cuando es marzo. Si trabajas con fechas legacy antes de 2000, ten cuidado con el método obsoleto getYear() que algunos proyectos antiguos aún usan.
getFullYear() siempre devuelve cuatro dígitos (2025, no 25) y reemplazó al peligroso getYear() que causó el problema Y2K. Para convertir el mes a 1-12, suma 1 antes de mostrar al usuario, o mejor aún, usa un array de nombres de meses (['Enero', 'Febrero', ...]) indexado directamente con getMonth(). Esto evita la aritmética y hace el código más legible.
No confundir getDate() con getDay()
getDate() devuelve el día del mes (1-31), mientras que getDay() devuelve el día de la semana (0=domingo, 6=sábado). Es un error común confundir estos dos métodos, especialmente porque getDay() no devuelve el día del mes como podrías esperar.
Método getDay(): Día de la Semana
getDay() devuelve 0-6 (domingo=0, sábado=6), y aquí viene la confusión mortal: NO devuelve el día del mes. Muchos desarrolladores esperan que getDay() devuelva el día del mes (1-31) por el nombre, pero eso es getDate(). Esta confusión causa bugs donde intentas mostrar "15 de enero" pero obtienes "3 de enero" porque getDay() devolvió 3 (miércoles). Ten especial cuidado: domingo es 0, no 1, diferente a estándares ISO donde lunes es 1.
Para convertir el número a nombre, usa un array indexado. Si trabajas con APIs internacionales que usan ISO 8601 (lunes=1, domingo=7), necesitas ajustar: (getDay() + 6) % 7 + 1 convierte de JS (dom=0) a ISO (lun=1). Este ajuste es común cuando sincronizas con backends que usan estándares diferentes.
Métodos para Extraer Componentes de Tiempo
Los métodos de tiempo extraen hora (0-23), minutos (0-59), segundos (0-59) y milisegundos (0-999). Ten cuidado: getHours() usa formato 24 horas, no 12 horas con AM/PM. Si necesitas formato 12 horas, debes convertir manualmente (hora % 12 || 12). Para medir duración de operaciones, usa Date.now() o performance.now(), no crees objetos Date repetidamente, es menos eficiente.
getMilliseconds() devuelve solo los milisegundos del segundo actual (0-999), NO el timestamp completo. Muchos confunden esto: si son las 10:30:45.500, getMilliseconds() devuelve 500, no el timestamp desde 1970. Para el timestamp usa getTime(). Esta distinción es crítica cuando mides tiempos de ejecución o sincronizas eventos.
Formateo de hora con ceros
Para mostrar horas, minutos o segundos con ceros a la izquierda (ej: "09:05:01"), usa el método padStart(2, '0') de strings. Esto es especialmente útil cuando necesitas un formato de hora consistente.
Ejemplo: Crear un Reloj Digital
Un reloj digital simple demuestra el uso práctico de métodos de tiempo. El desafío: los métodos devuelven números sin padding (9 en lugar de 09), creando formatos inconsistentes (9:5:3 vs 09:05:03). padStart(2, '0') soluciona esto convirtiendo el número a string y agregando ceros a la izquierda si es necesario.
Para un reloj en tiempo real, llama esta función con setInterval(). Precaución: usar setInterval(formatearHora, 1000) no garantiza actualización exacta cada segundo debido a la precisión limitada de timers en JavaScript. Para relojes críticos, calcula la diferencia con Date.now() en cada iteración y ajusta.
Métodos UTC: Tiempo Universal Coordinado
Los métodos UTC devuelven componentes en tiempo universal coordinado (UTC), ignorando la zona horaria local. Cada método get tiene su equivalente UTC: getUTCFullYear(), getUTCMonth(), getUTCDate(), etc. La diferencia puede ser dramática: en Sydney (UTC+11), el 1 de enero a las 10:00 hora local es 31 de diciembre a las 23:00 UTC del día anterior. Esto causa bugs críticos en aplicaciones globales cuando mezclas métodos locales y UTC.
Los métodos UTC son esenciales para almacenamiento en bases de datos y comunicación con APIs. Si guardas fechas usando métodos locales, usuarios en diferentes zonas horarias verán fechas diferentes para el mismo timestamp. La arquitectura correcta: almacena siempre en UTC (usando métodos UTC o timestamps), convierte a local solo al mostrar al usuario final.
Zona horaria en métodos locales
Los métodos locales (sin UTC) devuelven valores según la zona horaria configurada en el sistema donde se ejecuta el código. Esto puede causar inconsistencias si el código se ejecuta en diferentes zonas horarias. Considera usar métodos UTC para consistencia.
Comparación: Local vs UTC
La regla de oro para elegir entre local y UTC: usa local para UI (mostrar fechas al usuario en su zona horaria), usa UTC para todo lo demás (almacenamiento, logs, cálculos, comparaciones, APIs). Mezclarlos causa bugs insidiosos: reportes que muestran fechas del día anterior, eventos que aparecen en horas incorrectas, comparaciones que fallan dependiendo de la zona horaria del servidor.
Este ejemplo revela el peligro: el mismo timestamp muestra componentes diferentes en local vs UTC. En zonas horarias cerca del meridiano de Greenwich (UTC±0), la diferencia es mínima y los bugs pueden pasar inadvertidos en testing, pero explotan en producción cuando usuarios en UTC+12 o UTC-12 reportan fechas incorrectas. Siempre testea con usuarios simulados en zonas horarias extremas.
Métodos Adicionales
Además de los métodos get para componentes individuales, JavaScript ofrece métodos adicionales que proporcionan información esencial para casos de uso profesionales:
- <strong>getTime():</strong> Timestamp en milisegundos desde 1970, ideal para comparaciones y cálculos
- <strong>getTimezoneOffset():</strong> Diferencia en minutos entre zona local y UTC
- <strong>valueOf():</strong> Equivalente a getTime(), útil en coerción implícita
- <strong>toString():</strong> Representación legible en zona local (evita usarlo para parseo)
Estos métodos son fundamentales cuando trabajas con fechas en aplicaciones profesionales que requieren precisión, sincronización entre zonas horarias, o integración con APIs externas.
getTime(): Timestamp en Milisegundos
getTime() devuelve milisegundos desde la época Unix (1 enero 1970 00:00:00 UTC). Este número es universal: independiente de zona horaria, navegador, o configuración regional. Por esto, timestamps son el formato preferido para transmitir fechas en APIs REST, almacenar en bases de datos, y realizar operaciones matemáticas. Sumar 86400000 ms (1 día) a un timestamp es aritmética simple, mientras que sumar 1 día con métodos set requiere considerar horario de verano y cambios de mes/año.
Comparar fechas con getTime() evita errores sutiles de zona horaria. Dos objetos Date con el mismo timestamp son el mismo momento en el tiempo, incluso si sus métodos get locales devuelven componentes diferentes. Para comparar fechas, SIEMPRE usa getTime() o el operador < >, nunca compares componentes individuales (getFullYear(), getMonth(), etc.) porque ignoran el contexto completo.
getTimezoneOffset(): Offset de Zona Horaria
getTimezoneOffset() devuelve la diferencia en minutos entre la hora local y UTC. Aquí está la trampa: el signo es inverso a la intuición. Un valor positivo significa que la hora local está DETRÁS de UTC (al oeste), no adelante. Por ejemplo, EST (UTC-5) devuelve +300 minutos, no -300. Esta inversión confunde a muchos desarrolladores y causa errores al convertir zonas horarias manualmente.
El offset cambia dinámicamente con horario de verano (DST). En zonas con DST, el mismo código ejecutado en enero y julio devuelve valores diferentes (diferencia de 60 minutos). Esto significa que NO puedes cachear el offset una vez y reutilizarlo. Para detección confiable de zona horaria, usa Intl.DateTimeFormat().resolvedOptions().timeZone, no intentes derivarla solo del offset.
Errores Comunes con Métodos Get
Al trabajar con métodos get, hay varios errores comunes que pueden causar bugs difíciles de detectar. Conocer estos patrones problemáticos te ayudará a escribir código más robusto y evitar problemas en producción.
Error: Confundir getDate() con getDay()
El error número 1 con fechas: confundir getDate() (día del mes, 1-31) con getDay() (día de semana, 0-6). El nombre es engañoso porque ambos parecen referirse al "día". Este bug es silencioso: no hay excepciones, solo obtienes un número incorrecto que puede pasar inadvertidos en testing. Común en código que intenta mostrar "15 de enero" pero muestra "3 de enero" porque usó getDay() que devolvió 3 (miércoles).
Mnemotecnia: "Date" = fecha del calendario (15 de enero), "Day" = día de la semana (miércoles). O piensa "Day of Week" para getDay(). En código crítico, considera nombrar variables descriptivamente: dayOfMonth = getDate(), dayOfWeek = getDay(). Esto previene confusiones cuando revisas el código meses después.
Error: Olvidar que getMonth() es 0-indexado
Otro error común es olvidar que getMonth() devuelve un valor 0-indexado. Esto significa que enero es 0, no 1. Si necesitas mostrar el mes al usuario o realizar cálculos, debes ajustar este valor sumando 1.
Una práctica común es crear un array con los nombres de los meses y usar el valor devuelto por getMonth() como índice. Esto evita la necesidad de sumar 1 y proporciona directamente el nombre del mes en formato legible.
Error: Hora sin Ceros a la Izquierda
Mostrar hora sin padding crea formatos inconsistentes que parecen no profesionales: "9:5:1" en lugar de "09:05:01". Los métodos get devuelven números puros (9, no "09"), por lo que concatenar directamente produce strings de ancho variable que desalinean interfaces. Este error es cosmético pero afecta la percepción de calidad, especialmente en dashboards, relojes digitales, o logs.
padStart(2, '0') convierte números a strings de dos caracteres, agregando ceros a la izquierda si es necesario. Alternativa antigua (pre-ES2017): ('0' + num).slice(-2), pero padStart es más legible. Para producción con múltiples formatos, considera Intl.DateTimeFormat que maneja padding, localización, y formatos complejos automáticamente sin manipulación manual de strings.
Resumen: Métodos Get de Date
Conceptos principales:
- •getFullYear() devuelve el año de 4 dígitos
- •getMonth() devuelve 0-11 (enero=0, diciembre=11)
- •getDate() devuelve el día del mes (1-31)
- •getDay() devuelve el día de la semana (0=domingo, 6=sábado)
- •Los métodos UTC ignoran la zona horaria local
Mejores prácticas:
- •Usa arrays para convertir números a nombres de meses/días
- •Aplica padStart(2, '0') para formatear horas con ceros
- •Usa métodos UTC para almacenamiento y cálculos
- •Usa métodos locales para mostrar al usuario
- •Valida fechas inválidas con isNaN(date.getTime())