Generador de año aleatorio

Armazenar um ano parece a tarefa mais simples do mundo — é um número inteiro, afinal. Mas essa aparente simplicidade produziu duas das crises de software mais caras da história. A primeira foi o problema do Ano 2000, o Y2K: durante décadas, programadores economizavam memória armazenando o ano com apenas 2 dígitos (`98` em vez de `1998`), assumindo implicitamente que o século era sempre 19. Quando a virada para o ano 2000 se aproximou, bancos, governos e empresas de aviação descobriram que seus sistemas tratariam `00` como 1900. O custo estimado de correção mundial superou 100 bilhões de dólares. A segunda crise, menos conhecida mas ainda pendente, é o problema de 2038: sistemas que armazenam timestamps Unix em inteiros de 32 bits vão esgotar seu espaço no dia 19 de janeiro de 2038, às 03:14:07 UTC — e vários sistemas embarcados legados ainda enfrentarão isso.

A escolha do ano como unidade também revela conflitos culturais profundos. O calendário Gregoriano, implantado pelo papa Gregório XIII em 1582 para corrigir a deriva do Juliano, não foi adotado por todos de imediato: a Rússia só o adotou em 1918, a Grécia em 1923. Esse atraso gerou registros históricos com datas duplas — cartas da época tinham cabeçalho como `12/22 fevereiro 1700`. Quando sistemas modernos importam dados históricos, esses saltos criam anomalias silenciosas. A representação canônica atual em software é o `int` de 4 bytes (ou `bigint` de 8), mais do que suficiente para o calendário humano, mas já tivemos que aprender essa lição da maneira difícil.

Este gerador produz anos inteiros aleatórios dentro de uma faixa configurável — ideal para popular séries históricas, testar filtros de data por período, simular coortes de usuários por ano de nascimento e verificar comportamento de interfaces que exibem intervalos de tempo. Um uso prático que faço com frequência: gerar lotes de anos para alimentar testes de validação de regras de negócio que dependem de cálculos de anos fiscais ou prazos de vencimento — campos onde um ano fora do intervalo esperado costuma revelar bugs silenciosos.

Storing a year sounds like the simplest task in software — it is just an integer, after all. But that apparent simplicity produced two of the most expensive software crises in history. The first was the Year 2000 problem, Y2K: for decades, programmers saved memory by storing the year in only 2 digits (`98` instead of `1998`), implicitly assuming the century was always 19. When the year 2000 approached, banks, governments, and aviation companies discovered their systems would treat `00` as 1900. The worldwide cost of fixing that exceeded an estimated 100 billion dollars. The second crisis, lesser known but still pending, is the Year 2038 problem: systems that store Unix timestamps as 32-bit integers will run out of space on January 19, 2038, at 03:14:07 UTC — and many legacy embedded systems will still face it.

The choice of year as a unit also reveals deep cultural conflicts. The Gregorian calendar, introduced by Pope Gregory XIII in 1582 to correct the drift of the Julian calendar, was not immediately adopted by everyone: Russia switched only in 1918, Greece in 1923. That lag produced historical records with double dates — letters from that era had headers like `Feb 12/22, 1700`. When modern systems import historical data, those jumps create silent anomalies. The canonical representation in software today is a 4-byte `int` (or 8-byte `bigint`), more than sufficient for the human calendar — but we had to learn that lesson the hard way.

This generator produces random whole years within a configurable range — ideal for populating historical series, testing date-range filters, simulating user cohorts by birth year, and checking how interfaces behave when displaying time intervals. A practical use I come back to often: generating year batches to feed validation tests for business rules that depend on fiscal year calculations or expiration deadlines — fields where a year outside the expected range tends to reveal silent bugs.

Almacenar un año parece la tarea más sencilla del mundo — es solo un número entero, al fin y al cabo. Pero esa aparente simplicidad produjo dos de las crisis de software más costosas de la historia. La primera fue el problema del Año 2000, el Y2K: durante décadas, los programadores ahorraban memoria almacenando el año con solo 2 dígitos (`98` en lugar de `1998`), asumiendo implícitamente que el siglo siempre era el 19. Cuando se acercó el año 2000, bancos, gobiernos y empresas de aviación descubrieron que sus sistemas tratarían el `00` como 1900. El costo estimado de corrección mundial superó los 100.000 millones de dólares. La segunda crisis, menos conocida pero aún pendiente, es el problema de 2038: los sistemas que almacenan marcas de tiempo Unix en enteros de 32 bits agotarán su espacio el 19 de enero de 2038 a las 03:14:07 UTC — y muchos sistemas embebidos heredados todavía lo enfrentarán.

La elección del año como unidad también revela conflictos culturales profundos. El calendario gregoriano, implantado por el papa Gregorio XIII en 1582 para corregir la deriva del juliano, no fue adoptado de inmediato por todos: Rusia lo adoptó recién en 1918, Grecia en 1923. Ese retraso generó registros históricos con fechas dobles — cartas de la época tenían encabezados como `12/22 febrero 1700`. Cuando sistemas modernos importan datos históricos, esos saltos crean anomalías silenciosas. La representación canónica actual en software es el `int` de 4 bytes (o `bigint` de 8), más que suficiente para el calendario humano, pero tuvimos que aprender esa lección de la manera difícil.

Este generador produce años enteros aleatorios dentro de un rango configurable — ideal para poblar series históricas, probar filtros de fecha por período, simular cohortes de usuarios por año de nacimiento y verificar el comportamiento de interfaces que muestran intervalos de tiempo. Un uso práctico al que recurro con frecuencia: generar lotes de años para alimentar pruebas de validación de reglas de negocio que dependen de cálculos de años fiscales o fechas de vencimiento — campos donde un año fuera del intervalo esperado suele revelar bugs silenciosos.