AssemblyFileVersions: 2.0.0.071005 is bad, but 2.0.0.061005 is good

I was unhappily surprised this morning when I compiled a new build of an assembly and changed the assembly file version attribute from 2.0.0.061005 to 2.0.0.070105: I got this wicked warning from the C# compiler:

warning CS1607: Assembly generation -- The version '2.0.0.070105' specified for the 'file version' is not in the normal 'major.minor.build.revision' format

Err... huh? So I tried with just the '6' changed into '7', and that was enough to create this warning. The documentation on this error is of course as always pretty helpful:

Al.exe detected ill-formed version information specified with the /fileversion or /productversion options.

Looking up the AssemblyFileVersionAttribute's constructor, I see:

The file version is normally a string of four numbers, separated by periods, reflecting the major version number, minor version number, build number, and revision number; for example, "1.0.4309.00". If version is not in this format, a compiler warning occurs, and the results displayed in the file properties dialog are unpredictable. Wildcards are not supported.

So also not any sign of "'whoa, dude, you really think we're going to accept numbers higher than '70000' ?"-related remarks. If someone knows why this warning is showing up, please let me know. Oh, it's not the '0' in front of the 7, as that 0 was also there with 061005, which was apparently acceptable. 2.0.70105.0 also is wrong, so it's apparently a rule somewhere that revision numbers have to obey a secret rule: "Thou Shall Not Make Revisions with Numbers Higher than 70000"... well, what about a revision number that's related to say... a date?

Update: I had a little brainwave and realized: the darn number has to fit in 16 bits!. So I tried 65535, and it was an acceptable number, but 65536 isn't. . Welcome to the 64bit era!