This is more of a silly bit of trivia, but if you don't care about perfect precision (who cares if you give or take a second when talking about centuries?) then as
TotalTime is a double, the maximum value it can store is
I am not sure how overflows work in C#, but if you run the game for longer than this, I guess it would either go back to something like
-1.798*10^308, or simply not change. It also depends on how it is implemented internally.
That said, that number of milliseconds is pretty big. If you compare it to the hypothetical age of the universe, it's... Uh... Well it's still pretty big.
Of course, as Sam said, the time is actually stored in ticks (tenths of a nanosecond?), so you would run into the "limit" after a "much shorter" time period. It's still something like a cube of a googol times the age of the universe.
I'm not sure how
GameTime stores time, exactly, so this also means that you may never actually see
TotalMilliseconds output get "close" to its maximum value. Although, if it's packaging time into days and years whenever the ticks value gets high enough, and not just when you call the getter, then the timer will increase until the maximum value of
double in years, which is even higher.
If, for some reason, your game should have such plentiful content as to require spans of time in which a great many universes are born and perish to fully explore, there exist specialized data types for storing arbitrarily large numbers. Java has a
BigDecimal whose size is basically limited by your RAM (and through virtual memory, even hard disk space). Apparently, C# doesn't have
BigDecimal, but it has
Should you make such an epic-scaled game, doubtless to be played by the very gods themselves, you would probably start by duplicating the
BigDecimal class, and then reimplementing the
GameTime class (or even just periodically adding
GameTime's value to your
BigDecimal) to use it.