Calculadora de idade

Calcular a idade parece trivial — você pega o ano atual e subtrai o ano de nascimento — mas qualquer programador que já implementou isso de verdade sabe que a realidade é bem mais complicada. O problema começa no próprio calendário: o Calendário Gregoriano, adotado pelo Papa Gregório XIII em 1582 para corrigir erros acumulados do Calendário Juliano (introduzido por Júlio César em 45 a.C.), não tem todos os meses com o mesmo número de dias, e os anos bissextos — inseridos para compensar que a revolução terrestre não dura exatamente 365 dias — adicionam uma camada extra de complexidade. A ISO 8601, publicada em 1988 e revisada em 2004, padronizou o formato YYYY-MM-DD que hoje domina APIs, bancos de dados e sistemas de saúde, mas ainda há sistemas legados em produção que guardam datas como strings no formato DD/MM/AAAA ou, pior ainda, como número serial do Excel (onde 1 = 1 de janeiro de 1900).

Há um caso especial que nunca deixa de causar discussão: pessoas nascidas em 29 de fevereiro. Elas só têm uma data de aniversário 'real' a cada 4 anos. No Japão, a lei determina que o aniversário legal é 28 de fevereiro; no Brasil e em outros países, a convenção mais comum é usar 1º de março. Mas há algo ainda mais interessante: o sistema de idade coreano. Na Coreia do Sul, a tradição era que todos nascem com 1 ano de idade e ganham mais 1 ano no Ano Novo coreano — não no aniversário. Uma pessoa nascida em 31 de dezembro poderia estar com '2 anos' no segundo dia de vida. A Coreia do Sul aboliu oficialmente esse sistema em junho de 2023 e migrou para o sistema ocidental de contagem de idade. Em programação, o erro clássico é fazer `ageYears = currentYear - birthYear` sem verificar se o aniversário já passou neste ano — uma linha que garante resultado errado durante vários meses por ano.

A idade calculada com precisão tem implicações legais e de negócio que vão muito além de uma curiosidade: maioridade civil, habilitação para dirigir, elegibilidade para votar, consentimento médico, aposentadoria — tudo isso depende de um cálculo de data correto. Nos sistemas de software, a biblioteca `date-fns` do JavaScript calcula `differenceInYears` considerando corretamente se o aniversário já passou. Em Python, `relativedelta` da biblioteca `dateutil` é a forma mais robusta. Há também a questão do Year 2038 problem: timestamps Unix de 32 bits, contados em segundos a partir de 1º de janeiro de 1970 00:00:00 UTC — o Unix Epoch — transbordam em 19 de janeiro de 2038, afetando sistemas legados e dispositivos embarcados que ainda usam inteiros de 32 bits. Esta ferramenta calcula anos, meses e dias completos de diferença entre qualquer data de nascimento e uma data de referência, direto no navegador.

Calculating age seems trivial — take the current year and subtract the birth year — but any developer who has truly implemented this knows the reality is far more complex. The problem begins with the calendar itself: the Gregorian Calendar, adopted by Pope Gregory XIII in 1582 to correct accumulated errors from the Julian Calendar (introduced by Julius Caesar in 45 BC), does not have months with uniform lengths, and leap years — inserted to compensate for the fact that Earth's revolution is not exactly 365 days — add an extra layer of complexity. ISO 8601, published in 1988 and revised in 2004, standardized the YYYY-MM-DD format that today dominates APIs, databases, and healthcare systems, but there are still legacy systems in production storing dates as DD/MM/YYYY strings or, worse, as Excel serial numbers (where 1 = January 1, 1900).

There is a special case that never stops generating debate: people born on February 29th. They only have a 'real' birthday every 4 years. In Japan, the law states that the legal birthday is February 28th; in most Western countries the most common convention is March 1st. But there is something even more interesting: the Korean age system. In South Korea, the tradition was that everyone is born 1 year old and gains another year on the Korean New Year — not on their birthday. Someone born on December 31st could be '2 years old' on their second day of life. South Korea officially abolished this system in June 2023 and migrated to the Western age counting system. In programming, the classic mistake is `ageYears = currentYear - birthYear` without checking whether this year's birthday has already passed — a single line that guarantees a wrong result for several months each year.

A precisely calculated age has legal and business implications that go far beyond trivia: legal adulthood, driving eligibility, voting rights, medical consent, retirement — all depend on a correct date calculation. In software, JavaScript's `date-fns` library calculates `differenceInYears` correctly accounting for whether the birthday has passed. In Python, `relativedelta` from the `dateutil` library is the most robust approach. There is also the Year 2038 problem: 32-bit Unix timestamps, counted in seconds from January 1, 1970 00:00:00 UTC — the Unix Epoch — overflow on January 19, 2038, affecting legacy systems and embedded devices still using 32-bit integers. This tool calculates complete years, months, and days between any birth date and a reference date, directly in the browser.

Calcular la edad parece trivial — tomas el año actual y restas el año de nacimiento — pero cualquier programador que lo haya implementado de verdad sabe que la realidad es bastante más compleja. El problema comienza en el propio calendario: el Calendario Gregoriano, adoptado por el Papa Gregorio XIII en 1582 para corregir los errores acumulados del Calendario Juliano (introducido por Julio César en el 45 a.C.), no tiene meses con la misma cantidad de días, y los años bisiestos — insertados para compensar que la revolución terrestre no dura exactamente 365 días — agregan una capa extra de complejidad. La ISO 8601, publicada en 1988 y revisada en 2004, estandarizó el formato YYYY-MM-DD que hoy domina las APIs, bases de datos y sistemas de salud, pero todavía hay sistemas legacy en producción que guardan fechas como cadenas en formato DD/MM/AAAA o, peor aún, como números seriales de Excel (donde 1 = 1 de enero de 1900).

Hay un caso especial que nunca deja de generar debate: las personas nacidas el 29 de febrero. Solo tienen una fecha de cumpleaños 'real' cada 4 años. En Japón, la ley establece que el cumpleaños legal es el 28 de febrero; en la mayoría de los países occidentales, la convención más común es el 1 de marzo. Pero hay algo aún más interesante: el sistema de edad coreano. En Corea del Sur, la tradición era que todos nacen con 1 año de edad y ganan otro año en el Año Nuevo coreano — no en su cumpleaños. Alguien nacido el 31 de diciembre podía tener '2 años' al segundo día de vida. Corea del Sur abolió oficialmente este sistema en junio de 2023 y migró al sistema occidental de conteo de edad. En programación, el error clásico es hacer `ageYears = currentYear - birthYear` sin verificar si el cumpleaños de este año ya pasó — una sola línea que garantiza un resultado incorrecto durante varios meses al año.

Una edad calculada con precisión tiene implicaciones legales y de negocio que van mucho más allá de una curiosidad: mayoría de edad, habilitación para conducir, elegibilidad para votar, consentimiento médico, jubilación — todo depende de un cálculo de fecha correcto. En el software, la librería `date-fns` de JavaScript calcula `differenceInYears` considerando correctamente si el cumpleaños ya pasó este año. En Python, `relativedelta` de la librería `dateutil` es el enfoque más robusto. También existe el problema del Año 2038: los timestamps Unix de 32 bits, contados en segundos desde el 1 de enero de 1970 00:00:00 UTC — el Unix Epoch — desbordan el 19 de enero de 2038, afectando sistemas legacy y dispositivos embebidos que todavía usan enteros de 32 bits. Esta herramienta calcula años, meses y días completos entre cualquier fecha de nacimiento y una fecha de referencia, directamente en el navegador.