¿Hay una constante para el "fin del tiempo"?

12

Para algunos sistemas, el valor de tiempo 9999-12-31 se usa como el "fin del tiempo" como el fin del tiempo que la computadora puede calcular. Pero ¿y si cambia? ¿No sería mejor definir este tiempo como una variable incorporada?

En C y en otros lenguajes de programación, generalmente hay una variable como MAX_INT o similar para obtener el valor más grande que un entero podría tener. ¿Por qué no hay una función similar para MAX_TIME , es decir, establecer la variable en el "fin del tiempo" que para muchos sistemas generalmente es 9999-12-31? Para evitar el problema de la codificación en un año incorrecto (9999), ¿podrían estos sistemas introducir una variable para el "fin de los tiempos"?

** Ejemplo real **

End of validity date: 31/12/9999. (los documentos oficiales se listan así) El blogger quiere escribir una página que siempre esté en la parte superior, la página de bienvenida. Así que se le da una fecha lo más lejos posible en el futuro:

  

3000? Sí, la página de bienvenida que está viendo está publicada el 1 de enero.   3000. Por lo tanto, esta página se mantendrá en la parte superior del blog para siempre =) En realidad se publicó el 31 de agosto de 2007.

    
pregunta Niklas Rosencrantz 14.09.2012 - 09:13

7 respuestas

47

Pregúntese por qué necesita esa variable en primer lugar.

Lo más probable es que esté mintiendo acerca de sus datos: siempre que necesite una variable de "fin del tiempo", no se refiere al fin del tiempo real; más bien estás expresando cosas como "no hay un límite superior para esta fecha", "este evento continúa indefinidamente" o similar.

La solución correcta, entonces, es expresar estos intentos directamente en lugar de confiar en un valor mágico: usar tipos de fecha que puedan ser nulos (donde null indica "sin fecha de finalización establecida"), agregar un campo booleano "indefinido", usar una envoltura polimórfica (que puede ser una fecha real o un valor especial "indefinido"), o lo que sea que su lenguaje de programación tenga para ofrecer.

Por supuesto, la solución correcta no siempre es factible, por lo que podría terminar usando un valor mágico después de todo, pero cuando lo haga, tendrá que decidir un valor adecuado para cada caso, porque las fechas no y no tiene sentido depende del dominio que está modelando: si está almacenando las marcas de tiempo de registro, 01/01/2999 es un "fin de tiempo" razonable; Las posibilidades de que su aplicación se siga utilizando en casi 1000 años a partir de ahora, creo, son prácticamente nulas. Consideraciones similares van para aplicaciones de calendario. Pero, ¿y si su software es para manejar datos científicos, por ejemplo, predicciones a largo plazo sobre el clima de la Tierra? Aquellos podrían querer mirar mil años en el futuro. O dar un paso más; La astronomía, un campo donde es perfectamente normal razonar en períodos de tiempo muy grandes del orden de miles de millones de años, tanto en el camino como en el futuro. Para aquellos, 01/01/2999 es un máximo arbitrario perfectamente ridículo. OTOH, un sistema de calendario que puede manejar intervalos de tiempo de diez billones de años en el futuro, no es práctico para un sistema de seguimiento de citas con el dentista, aunque solo sea por la capacidad de almacenamiento.

En otras palabras, no existe una mejor opción para un valor que sea incorrecto y arbitrario, por definición, para comenzar. Por esta razón, es muy raro ver uno definido en cualquier lenguaje de programación; los que lo hacen generalmente no lo llaman "fin del tiempo", sino algo como DATE_MAX (o Date.MAX ), y lo hacen para que signifique "el valor más grande que se puede almacenar en el tipo de fecha", no " el fin del tiempo "o" indefinidamente ".

    
respondido por el tdammers 14.09.2012 - 12:27
17

Como industria, hemos sido notoriamente miopes y arbitrarios en la búsqueda de guardar algunos bytes, por ejemplo,

  • 31 de diciembre de 99
  • 19 de enero de 2038
  • T + 50 años, cuando, con suerte, todos los sistemas en los que he participado se han extinguido o han sido reemplazados (o estoy muerto, lo que ocurra primero).

En mi humilde opinión, la mejor opción es quedarse con un nivel de abstracción apropiado y general en la "fecha máxima", y esperar que una solución común haya abordado el problema antes de que llegue el momento.

por ejemplo en .NET, DateTime.MaxValue es arbitrariamente 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000 . Entonces, si mis suposiciones sobre mi propia longevidad son falsas, y llega el año 10000, espero que una recompilación de mi aplicación con una versión posterior del marco de trabajo extienda DateTime.MaxValue (por ejemplo, cambiando su tipo subyacente) a un nuevo valor arbitrario y elimine el problema por otros milenios.

Editar

(Refuerza el punto de los detonadores de que en lugar de falsear una fecha artificial, que es más correcto resaltar explícitamente el hecho al consumidor de que no tenemos una fecha final).

Como alternativa al uso de null , que tiene la consecuencia negativa de ser compatible con el tipo con cualquier tipo de referencia (incluido .Net Nullable '), que probablemente causará problemas de NRE en los consumidores que se olvidan de verificar, en los idiomas de FP, es un lugar común utilizar una opción o Maybe Type alrededor de un valor que puede o no puede devolverse.

Pseudo código:

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

El beneficio de hacer esto es que obliga al consumidor a razonar en ambos casos. La coincidencia de patrones también es un lugar común aquí:

LeaseExpiryDate(myHome) match {
     case Some(expiryDate) => "Expired"
     case None => "No Expiry"
}
    
respondido por el StuartLC 14.09.2012 - 15:07
7

Probablemente quieras un algebraic data type con variante para infinito big date . Luego defina la comparación, en la que la variante infinite siempre será más grande que cualquier otra date .

Ejemplo en 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

enlace

    
respondido por el Sarge Borsch 16.09.2012 - 17:27
2

Almacene sus tiempos como un número de punto flotante IEE754 de doble precisión de 64 bits, y puede usar +INF . No use precisión simple, solo tiene una precisión de 7 dígitos, que es un poco bajo para una fecha.

    
respondido por el MSalters 10.10.2012 - 18:31
1

Cocoa / Objective-C tiene métodos de fábrica [NSDate distantPast] y [NSDate distantFuture] que representan exactamente el tipo de cosas a las que te refieres.

Los valores devueltos por la implementación actual son constantes que representan alrededor de 0 AD y 4000 AD, aunque no están garantizados ni documentados.

    
respondido por el grahamparks 08.03.2013 - 16:18
0

En general, no existe tal valor, porque no sería útil como construcción de lenguaje.

MAX_INT y sus parientes sirven para un propósito. Se pueden usar en su código para verificar los desbordamientos. Esto es útil si va a crear y administrar grandes objetos de datos en matrices, vectores, lo que sea. También es un valor bastante específico de la plataforma.

El caso de uso para un valor MAX_DATE es más difícil de ver. Por lo general, estos son solo valores, no se usan como parte de la estructura del programa y, por lo tanto, el valor que circula alrededor no tendría consecuencias desastrosas para el programa (aunque puede afectar a los datos). Además, los tipos de fecha y hora en C, C ++, etc. suelen definirse más estrictamente; y para que las personas que escriben el programa no tengan que preocuparse de que pueda cambiar entre plataformas.

    
respondido por el TZHX 14.09.2012 - 10:29
0

En un proyecto que hicimos, tuvimos una situación en la que el tamaño de algunas bases de datos se realizó de una manera que no sería sostenible después de 30 años de uso del software. Cuando el cliente le preguntó a nuestro ingeniero principal en ese momento: "Bueno, ¿qué vamos a hacer después de 30 años de usar su software?" Nuestro ingeniero principal, fresco como un pepino, respondió encogiéndose de hombros: "¡Iremos a tomar una cerveza!"

El punto es, solo use la fecha que es lo suficientemente lejos en el futuro. Es probable que su software se actualice o reemplace para entonces. :)

    
respondido por el Vladimir Stokic 26.07.2017 - 18:04

Lea otras preguntas en las etiquetas