Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

For some systems, the time value 9999-12-31 is used as the "end of time" as the end of the time that the computer can calculate. But what if it changes? Wouldn't it be better to define this time as a builtin variable?

In C and other programming languages there usually is a variable such as MAX_INT or similar to get the largest value an integer could have. Why is there not a similar function for MAX_TIME i.e. set the variable to the "end of time" which for many systems usually is 9999-12-31. To avoid the problem of hardcoding to a wrong year (9999) could these systems introduce a variable for the "end of time"?

*Real example *

The blogger wants to write a page that is always on top, the welcome page. So it's given a date as far in the future as possible:

3000? Yes, the welcome page which you're facing is posted at 1 january 3000. So this page will be kept on the top of the blog forever =) It's actually posted at 31 august 2007.

share|improve this question
Why? This seems like problem that could be solved by implementing correct algorithm or data structure. –  Euphoric Sep 14 '12 at 7:15
I guess most people aren't much worried about the Y10K problem yet :-) Especially as before that we are bound to have a Y2038 problem, and probably a couple more... –  Péter Török Sep 14 '12 at 7:20
@Thorbjörn, yes, probably most live systems will have been migrated by then. Nevertheless, there still may be a currently inestimable amount of old embedded systems, legacy databases, files in obsolete file formats etc. –  Péter Török Sep 14 '12 at 7:51
In the program I'm currently working with, there is a constant INFINITY with a value of 4012-12-31. Don't ask... –  user281377 Sep 14 '12 at 7:55
I think the Mayan calender has an "end of time" constant = 2012-12-21 ;-) –  nikie Sep 14 '12 at 11:35
show 13 more comments

6 Answers

up vote 1 down vote accepted

Store your times as a 64 bits IEE754 double precision floating point number, and you can use +INF. Don't use single-precision, that's only accurate to 7 digits which is a bit low for a date.

share|improve this answer
add comment

Ask yourself why you need such a variable in the first place.

Most likely, you are lying about your data: whenever you need an "end of time" variable, you are not referring to the actual end of time; rather you are expressing things like "there is no upper bound for this date", "this event continues indefinitely", or similar.

The correct solution, then, is to express these intents directly instead of relying on a magic value: use nullable date types (where null indicates "no end date set"), add an "indefinite" boolean field, use a polymorphic wrapper (which can be either a real date or a special "indefinite" value), or whatever your programming language has to offer.

Of course, the correct solution is not always feasible, so you might end up using a magic value after all, but when you do, you have to decide on a suitable value on a per-case basis, because which dates do and do not make sense depends on the domain you're modelling - if you're storing log timestamps, 01/01/2999 is a reasonable "end of time"; the chances of your application still being used almost 1000 years from now are, I would reckon, practically zero. Similar considerations go for calendar applications. But what if your software is to handle scientific data, say, long-term predictions about the Earth's climate? Those might actually want to look a thousand years into the future. Or take it one step further; astronomy, a field where it is perfectly normal to reason in very large timespans on the order of billions of years, both into the path and the future. For those, 01/01/2999 is a perfectly ridiculous arbitrary maximum. OTOH, a calendar system that is able to handle timespans ten trillion years into the future is hardly practical for a dentist appointment tracking system, if only because of storage capacity.

In other words, there is no single best choice for a value that is wrong and arbitrary by definition to begin with. This is why it is really uncommon to see one defined in any programming language; those that do usually don't name it "end of time", but rather something like DATE_MAX (or Date.MAX), and take it to mean "the largest value that can be stored in the date datatype", not "the end of time" or "indefinitely".

share|improve this answer
using null to mean a special value isn't really any better than using that special value –  Ryathal Sep 14 '12 at 12:57
@Ryathal Well, I think there's no 'nullenium' bug, so it's at least a bit better... –  K.Steff Sep 14 '12 at 13:29
@Ryathal : actually it's not. There are a lot of actions you can perform on a magic number that you can't perform on null. –  Pieter B Sep 14 '12 at 13:29
@Ryathal - null in this case isn't being used as a special value, it's being used as the correct meaning of null, which is "missing". So if your field is ExpiryDate, which is more correct: null (meaning no expiry date) or END_OF_TIME (which doesn't exist, as far as we know). Clearly null or NoValue or something similar is the better solution. –  Scott Whitlock Sep 14 '12 at 16:33
@jwenting - They make no distinction because there isn't one. NULL means it does not exist or in more human terms the value is simply not defined. –  Ramhound Oct 10 '12 at 14:35
show 6 more comments

As an industry we have been notoriously short-sighted and arbitrary in the pursuit of saving a few bytes e.g.

  • 31 Dec 99
  • January 19 2038
  • T + 50 years, when hopefully all systems I've been involved in have become defunct or been replaced (or I'm dead, whichever comes first).

IMHO the best bet is to stay with a appropriate, mainstream level of abstraction on 'max date', and hope that a common solution has addressed the issue before the time arrives.

e.g. in .NET, DateTime.MaxValue is arbitrarily 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000. So if my assumptions about my own longevity are false, and the year 10000 arrives, I'm rather hoping that a recompile of my app with a later version of the framework will extend DateTime.MaxValue ( e.g by changing its underlying type) to a new arbitrary value and kick the problem further down the road for another few millennia.

share|improve this answer
Many thanks for a very good answer. –  909 Niklas Oct 4 '12 at 22:32
Duh. Me blind. Nevermind. –  ott-- Mar 8 '13 at 15:22
add comment

You probably want an algebraic data type with variant for infinite big date. Then define comparison, in which infinite variant will be always bigger than any other date.

Example in 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


share|improve this answer
Quote the code in your answer for posterity. –  deadly Oct 9 '12 at 15:01
add comment

There generally isn't such a value, because it would not be useful as a language construct.

MAX_INT and it's kin all serve a purpose. They can be used in your code to check against overflows. This is useful if you're going to be creating and managing large data objects in arrays, vectors, whatever. It's also a fairly platform-specific value.

The use case for a MAX_DATE value is more difficult to see. Typically these are just values, they're not used as part of the structure of the program, and so the value circling around wouldn't have disastorous consequences to the program (though it may to the data). Also, the date and time types in C, C++ etc. are usually more strictly defined; and so the people writing the program don't have to worry that it may change between platforms.

share|improve this answer
add comment

Cocoa/Objective-C has factory methods [NSDate distantPast] and [NSDate distantFuture] that represent exactly the kind of thing you're referring to.

The values returned by the current implementation are constants representing circa 0 AD and 4000 AD, although these aren't guaranteed or documented.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.