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 **End of validity date: 31/12/9999. (official documents are listed like this)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.
Is there a constant for end of time?
programming practices;time;date format
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.