9999 Year Restriction Question

[Droll (OP)]

As you might have read in the "Known Issues" thread the maximum year is 9999. My question is when the year is 9999 30 December does the game play normally without updating the year or is it basically Game Over?

[Father Tim]

No idea.  Why don't you run the experiment and tell us?

[Desdinova]

I would guess that you would get a ton of invalid DateTime exceptions every turn but it probably wouldn't break the game.

[GodEmperor]

Overflow errors probably. Like in VB6 when you had more than 2.4T fuel on a planet.

[Migi]

As you might have read in the "Known Issues" thread the maximum year is 9999. My question is when the year is 9999 30 December does the game play normally without updating the year or is it basically Game Over?

It's a restriction because of how the game is coded, not a game over screen. Game may or may not function after this point is reached.
Please can we have a moment of silence for all the WH40k games this has snuffed out.

[Father Tim]

Only if we in turn take a moment of silence for all of my conventional start games that use a negative starting year in a wild guess at when we'll achieve space flight / first contact.

[Steve Walmsley]

As you might have read in the "Known Issues" thread the maximum year is 9999. My question is when the year is 9999 30 December does the game play normally without updating the year or is it basically Game Over?

It's a restriction because of how the game is coded, not a game over screen. Game may or may not function after this point is reached.
Please can we have a moment of silence for all the WH40k games this has snuffed out.

Actually, a restriction on the Windows DateTime object. You need to take it up with Microsoft

[Aloriel]

I'm really surprised that DateTime is restricted to merely 9999 years. 64 bit time supposedly can handle 300,000 years, and 32 bit time can't even handle past 2035. So, what the heck is DateTime using that breaks at 9999?

[JacenHan]

I think the problem is that five-digit years would cause visual overflow on some windows.

[Barkhorn]

2^64 is ~1.8e19 seconds, or ~584 billion years.  Considering 9999 isn't special in binary, 8-bit or hex, I think it's gotta be a decimal overflow thing.

[Steve Walmsley]

Here is the documentation from Microsoft:

https://docs.microsoft.com/en-us/dotnet/api/system.datetime?view=netframework-4.8

The DateTime value type represents dates and times with values ranging from 00:00:00 (midnight), January 1, 0001 Anno Domini (Common Era) through 11:59:59 P.M., December 31, 9999 A.D. (C.E.) in the Gregorian calendar.

[db48x]

For those wondering, the .Net DateTime objects store the time in a 64-bit number which holds the number of 100-nanosecond ticks since the start of year 0001. The year 9999 is an arbitrary cut-off put in by the authors or designers of .Net, but even without it the date would only go up to approximately year 29227.

Desdinova has it right; the game generates an exception every time it tried to do any arithmetic that resulted in a value in year 10000 or later; they've already been seen in testing. If you would like to see one for yourself, set your industry to produce a large enough number of facilities and it'll generate the exception when it estimates the completion date.

Supporting a larger range of years is possible, of course, but could be quite a lot of work. In the best case, Steve might be able to find and integrate a third-party library that does all the (quite complicated) date arithmetic using an interface which is compatible with the code as written, but stores the date in either more than 64 bits or at lower precision. In the worst case, he'd have to write all of the code himself, which is a task that I would not wish upon anybody. Just being able to format a date into a localized string in the user's locale and preferred date format is already a huge productivity boost. Even just considering the few hundred languages that Windows supports, it's a huge time saver not having to write that yourself. (Of course, there are over 7700 languages on Earth, so that task might not ever be finished…) And then there are time zones, which are a nightmare.

[Father Tim]

Supporting a larger range of years is possible, of course, but could be quite a lot of work. In the best case, Steve might be able to find and integrate a third-party library that does all the (quite complicated) date arithmetic using an interface which is compatible with the code as written, but stores the date in either more than 64 bits or at lower precision. In the worst case, he'd have to write all of the code himself, which is a task that I would not wish upon anybody. Just being able to format a date into a localized string in the user's locale and preferred date format is already a huge productivity boost. Even just considering the few hundred languages that Windows supports, it's a huge time saver not having to write that yourself. (Of course, there are over 7700 languages on Earth, so that task might not ever be finished…) And then there are time zones, which are a nightmare.

None of which is important to me.  I almost never start on Earth anyway, so the calendar is always wrong.  If Aurora adjusted 'days' and 'years' to my empire's homeworld I would be delighted.  If instead it kept 30-day months and 360-day years, I'd still be equally delighted to get negative dates back.  I wonder how Windows handles BCE (BC)?

Aurora doesn't need to know anything about time zones -- I don't care what the real-world time is now, I care about the game time.  And I'm disappointed that apparently all my games from now on are going to have to start from year 1 to get the maximum amount of play time, since I'me quite sure there's no way to change the in-game date.

[MasonMac]

Wouldn't it be possible to simply import a date-time object from a library that can handle those large numbers? If not, a work around could be to reset the clock to 0000, save the old years, and add it up.

[db48x]

Supporting a larger range of years is possible, of course, but could be quite a lot of work. In the best case, Steve might be able to find and integrate a third-party library that does all the (quite complicated) date arithmetic using an interface which is compatible with the code as written, but stores the date in either more than 64 bits or at lower precision. In the worst case, he'd have to write all of the code himself, which is a task that I would not wish upon anybody. Just being able to format a date into a localized string in the user's locale and preferred date format is already a huge productivity boost. Even just considering the few hundred languages that Windows supports, it's a huge time saver not having to write that yourself. (Of course, there are over 7700 languages on Earth, so that task might not ever be finished…) And then there are time zones, which are a nightmare.

None of which is important to me.  I almost never start on Earth anyway, so the calendar is always wrong.  If Aurora adjusted 'days' and 'years' to my empire's homeworld I would be delighted.  If instead it kept 30-day months and 360-day years, I'd still be equally delighted to get negative dates back.  I wonder how Windows handles BCE (BC)?

It'd be a huge amount of work, as I said. Of course it would be awesome if the game customized the calendar based on the geometry of your starting system, but it would probably also be a sign of mental illness.

The .Net API simply doesn't handle or allow BC dates at all. They're all before year 0001, so the API simply throws an exception saying that the date is invalid, same as if you go past year 9999.

Aurora doesn't need to know anything about time zones -- I don't care what the real-world time is now, I care about the game time.  And I'm disappointed that apparently all my games from now on are going to have to start from year 1 to get the maximum amount of play time, since I'me quite sure there's no way to change the in-game date.

True, I think it would be nice to have negative dates, and to play in the year 40,000. But it's an imperfect universe; we can't always get everything we want. As feature requests go, I think it's going to be pretty low down on the priority list; I can think of a few things I'd much rather have instead.

Wouldn't it be possible to simply import a date-time object from a library that can handle those large numbers? If not, a work around could be to reset the clock to 0000, save the old years, and add it up.

As I said, he could in principle use a third-party library. However, that could mean rewriting all the existing code that assumes that it's dealing with a built-in DateTime object. All the method names could be different, to name one possibility. The best case scenario would be a library that implements exactly the same interfaces as the built-in DateTime library, but stores dates in seconds rather than 100-nanosecond ticks. You should go search for it to see if it exists, or write one of your own.

Simply adding an offset to the year would get you pretty close, but it would technically be incorrect since the days of the week and the leap years won't line up. Maybe nobody would notice, or maybe fans of the game are obsessive enough to complain about it