Existe uma constante para o "fim dos tempos"?

Para alguns sistemas, o valor de tempo 9999-12-31 é usado como o "fim do tempo" como o fim do tempo que o computador pode calcular. Mas e se isso mudar? Não seria melhor definir esse tempo como uma variável interna?

Em C e outras linguagens de programação, geralmente existe uma variável como MAX_INTou similar para obter o maior valor que um número inteiro poderia ter. Por que não existe uma função semelhante para, por exemplo, MAX_TIMEdefinir a variável para o "fim dos tempos", que para muitos sistemas geralmente é 9999-12-31. Para evitar o problema de codificação codificada para um ano errado (9999), esses sistemas poderiam introduzir uma variável para o "fim dos tempos"?

** Exemplo real **

End of validity date: 31/12/9999.(os documentos oficiais estão listados assim) O blogueiro deseja escrever uma página que esteja sempre no topo, a página de boas-vindas. Portanto, é dada uma data o mais distante possível no futuro:

3000? Sim, a página de boas-vindas que você está enfrentando é postada em 1 de janeiro de 3000. Portanto, essa página será mantida no topo do blog para sempre =) Na verdade, é postada em 31 de agosto de 2007.

Pergunte a si mesmo por que você precisa dessa variável em primeiro lugar.

Provavelmente, você está mentindo sobre seus dados: sempre que precisar de uma variável "fim do tempo", não estará se referindo ao fim do tempo real; em vez disso, você está expressando coisas como "não há limite superior para esta data", "esse evento continua indefinidamente" ou semelhante.

A solução correta, então, é expressar essas intenções diretamente, em vez de confiar em um valor mágico: use tipos de data anuláveis ​​(onde nullindica "nenhuma data de término definida"), adicione um campo booleano "indefinido", use um invólucro polimórfico (que pode seja uma data real ou um valor "indefinido" especial) ou o que sua linguagem de programação tem a oferecer.

Obviamente, a solução correta nem sempre é viável; portanto, você pode acabar usando um valor mágico, mas quando o fizer, terá que decidir um valor adequado caso a caso, porque quais datas acontecem ou não faz sentido depende do domínio que você está modelando - se você estiver armazenando registros de data e hora do log, 01/01/2999 é um "fim do tempo" razoável; as chances de seu aplicativo ainda ser usado daqui a 1000 anos são, eu diria, praticamente zero. Considerações semelhantes são aplicáveis ​​aos aplicativos de calendário. Mas e se o seu software manipular dados científicos, por exemplo, previsões de longo prazo sobre o clima da Terra? Na verdade, eles podem querer olhar mil anos para o futuro. Ou dê um passo adiante; astronomia, um campo em que é perfeitamente normal raciocinar em períodos muito grandes da ordem de bilhões de anos, tanto no caminho quanto no futuro. Para aqueles, 01/01/2999 é um máximo arbitrário perfeitamente ridículo. OTOH, um sistema de calendário capaz de lidar com o período de tempo de dez trilhões de anos no futuro dificilmente é prático para um sistema de rastreamento de consultas com dentistas, mesmo que apenas por causa da capacidade de armazenamento.

Em outras palavras, não existe uma melhor opção para um valor errado e arbitrário por definição, para começar. É por isso que é realmente incomum ver um definido em qualquer linguagem de programação; aqueles que geralmente não o chamam de "fim dos tempos", mas sim algo como DATE_MAX(ou Date.MAX), e consideram "o maior valor que pode ser armazenado no tipo de dados da data", não "o fim dos tempos" ou "indefinidamente".

Como indústria, fomos notoriamente míopes e arbitrários na busca de salvar alguns bytes, por exemplo

• 31 dez 99
• 19 de janeiro de 2038
• T + 50 anos, quando, esperançosamente, todos os sistemas nos quais eu estive envolvido se tornaram extintos ou foram substituídos (ou eu estou morto, o que ocorrer primeiro).

IMHO, a melhor aposta é permanecer com um nível de abstração apropriado e mainstream em 'data máxima', e torcer para que uma solução comum resolva o problema antes que chegue o tempo.

por exemplo, no .NET, DateTime.MaxValue é arbitrariamente 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000. Portanto, se minhas suposições sobre minha própria longevidade forem falsas e o ano de 10000 chegar, espero que uma recompilação do meu aplicativo com uma versão posterior da estrutura se estenda DateTime.MaxValue(por exemplo, alterando seu tipo subjacente) para um novo valor arbitrário e chute o problema mais adiante no caminho por mais alguns milênios.

Editar

(Reforçando o argumento dos tdammers de que, em vez de falsificar uma data artificial, é mais correto destacar explicitamente o fato ao consumidor de que não temos uma data final.)

Como alternativa ao uso null, que tem a consequência negativa de ser compatível com qualquer tipo de referência (incluindo .Net Nullable`), o que provavelmente causará problemas de NRE em consumidores que se esquecem de verificar, nos idiomas do FP, é comum usar um Opção ou Talvez Digite wrapper em torno de um valor que pode ou não ser retornado.

Pseudo-código:

Option<DateTime> LeaseExpiryDate(Home rental) 
{
    if (... expiry date can be determined ...)
       return Some(rental.ExpiryDate);
    else
       return None;
}

O benefício de fazer isso é que ele força o consumidor a raciocinar nos dois casos. A correspondência de padrões também é comum aqui:

LeaseExpiryDate(myHome) match {
     case Some(expiryDate) => "Expired"
     case None => "No Expiry"
}

Você provavelmente quer um algebraic data typecom variante para infinito grande date. Em seguida, defina a comparação, na qual a infinitevariante será sempre maior que qualquer outra date.

Exemplo em Scala:

sealed abstract class SmartTime extends Ordered[SmartTime] { x =>
        def compare(y: SmartTime) = {
                x match {
                        case InfiniteFuture => 1
                        case InfinitePast => -1
                        case ConcreteTime(x) =>
                                y match {
                                        case InfiniteFuture => -1
                                        case InfinitePast => 1
                                        case ConcreteTime(y) => x compare y
                                }
                }
        }
}
case class ConcreteTime(t: Long) extends SmartTime
case object InfiniteFuture extends SmartTime
case object InfinitePast extends SmartTime

http://ideone.com/K5Kuk

Armazene seus horários como um número de ponto flutuante de precisão dupla IEE754 de 64 bits e você poderá usá-lo +INF. Não use precisão única, isso tem apenas 7 dígitos, o que é um pouco baixo para uma data.

O Cocoa / Objective-C possui métodos de fábrica [NSDate distantPast] e [NSDate distantFuture] que representam exatamente o tipo de coisa a que você está se referindo.

Os valores retornados pela implementação atual são constantes que representam cerca de 0 AD e 4000 AD, embora não sejam garantidos ou documentados.

Geralmente não existe esse valor, porque não seria útil como uma construção de linguagem.

MAX_INTe tudo isso serve a um propósito. Eles podem ser usados ​​no seu código para verificar estouros. Isso é útil se você estiver criando e gerenciando objetos de dados grandes em matrizes, vetores, o que for. Também é um valor bastante específico da plataforma.

O caso de uso de um MAX_DATEvalor é mais difícil de ver. Normalmente, esses são apenas valores, não são usados ​​como parte da estrutura do programa e, portanto, o valor circulando ao redor não teria conseqüências desastrosas para o programa (embora possa ser para os dados). Além disso, os tipos de data e hora em C, C ++ etc. geralmente são mais estritamente definidos; e, portanto, as pessoas que escrevem o programa não precisam se preocupar com a possibilidade de alteração entre as plataformas.

Em um projeto que realizamos, tivemos uma situação em que o dimensionamento de algum banco de dados era feito de uma maneira que não seria sustentável após 30 anos de uso do software. Quando o cliente perguntou ao nosso engenheiro chefe na época: "Bem, o que faremos depois de 30 anos usando o seu software?" Nosso engenheiro chefe, frio como um pepino, respondeu com um encolher de ombros: "Vamos tomar uma cerveja!"

A questão é: basta usar a data que for longe o suficiente no futuro. Provavelmente, seu software será atualizado ou substituído até então. :)