# Is there a limit to Gametime.TotalMilliseconds?

Gametime should always be increasing, and totalmilliseconds is going to be the largest value. So if the game is hypothetically run for 1 day, this value should 86 400 000.

This probably isn't a problem for most games, but I'm curious if there's some sort of fail safe mechanism if it does get too large, or if a limit even exists.

• Who wants to test it! :D – SpartanDonut Feb 3 '12 at 18:51

I’m afraid the answers here don’t understand that the limit is the Double’s mantissa. The maximum fully accurate value for GameTime.TotalMilliseconds is actually about 10,000 days.

TimeSpan’s internal representation is the Tick, which is defined as 1/10,000 milliseconds. TotalMilliseconds is a Double, which can only represent 2^53 different mantissa values. After 2^53 ticks, there is loss of information.

So the largest TimeSpan that can be represented as a Double with no loss of precision is:

2^53 ticks / 10000 ticksperms ≅ 900719925474 ms ≅ 10425 days

• I do not agree with this answer. The number of ticks is a signed 64-bit integer. The number of milliseconds is exposed as a double, but the number of milliseconds in 2^63 ticks is less than 2^53, so there's no floating-point loss in accuracy. – Jimmy Feb 6 '12 at 7:59
• @Jimmy: I am sorry that you disagree. But you cannot store 63 bits in a 53-bit mantissa without losing accuracy, that is a fact. And in a game, you need that sub-millisecond accuracy. Otherwise, why would TotalMilliseconds be a double and not a long? – sam hocevar Feb 6 '12 at 8:56
• 63 bits is never stored in a 53-bit mantissa! Here is my pseudo-TimeSpan, which is pretty close to how the real one works: gist.github.com/1753547. long.MaxValue / TicksPerMillisecond will never be larger than 2^53. TimeSpan does not actually track anything as a double internally. – Jimmy Feb 6 '12 at 17:35
• @Jimmy: there is something you are not understanding but I do not know what it is. Check ideone.com/1XLuJ to see how your class loses precision with 60-bit tick values. – sam hocevar Feb 6 '12 at 17:49
• that makes sense. I was assuming integral values for milliseconds. I've removed my own answer. – Jimmy Feb 6 '12 at 18:36

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 1.7976931348623157E+308.

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 BigInteger.

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.