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), and take it to mean "the largest value that can be stored in the date datatype", not "the end of time" or "indefinitely".