MIDL Compiler generates wrong year

Question

Using the MIDL compiler with IDL statements to generate a .TLB file, the compiler inserts a text line into the .TLB such as: Created by MIDL version 8.01.0628 at Mon Jan 18 19:14:07 2038. The year should be the year the .TLB was created (e.g., 2024), NOT 2038!

In researching the internet, there are discussions about year issues depending on how software (such as MIDL) store and represent dates/times internally.

I assume Microsoft is already aware of this and I just haven't found a discussion thread about it somewhere.

Answer 1

https://en.wikipedia.org/wiki/Year_2038_problem

The problem exists in systems which measure [Unix time](https://en.wikipedia.org/wiki/Unix_time"Unix time")—the number of seconds elapsed since the Unix [epoch](https://en.wikipedia.org/wiki/Epoch_(computing)"Epoch (computing)") (00:00:00 UTC on 1 January 1970)—and store it in a [signed 32-bit integer](https://en.wikipedia.org/wiki/Integer_(computer_science)"Integer (computer science)"). The data type is only capable of representing integers between −(231) and 231 − 1, meaning the latest time that can be properly encoded is 231 − 1 seconds after epoch (03:14:07 UTC on 19 January 2038). Attempting to increment to the following second (03:14:08) will cause the [integer to overflow](https://en.wikipedia.org/wiki/Integer_overflow"Integer overflow"), setting its value to −(231) which systems will interpret as 231 seconds before epoch (20:45:52 UTC on 13 December 1901). Systems using unsigned 32-bit integers will overflow in [2106](https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2106"Time formatting and storage bugs"). The problem resembles the [year 2000 problem](https://en.wikipedia.org/wiki/Year_2000_problem"Year 2000 problem") but arises from limitations in [base-2](https://en.wikipedia.org/wiki/Binary_number"Binary number") (binary) time representation, rather than base-10.

Computer systems that use time for critical computations may encounter fatal errors if the year 2038 problem is not addressed. Some applications that use future dates have already encountered the bug.[4[]](https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-:1-4)[5[]](https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-:2-5) The most vulnerable systems are those which are infrequently or never updated, such as [legacy](https://en.wikipedia.org/wiki/Legacy_system"Legacy system") and [embedded systems](https://en.wikipedia.org/wiki/Embedded_system"Embedded system"). Modern systems and software updates to legacy systems address this problem by using signed [64-bit](https://en.wikipedia.org/wiki/64-bit_computing"64-bit computing") integers instead of 32-bit integers, which will take 292 billion years to overflow—approximately 21 times the estimated [age of the universe](https://en.wikipedia.org/wiki/Age_of_the_universe"Age of the universe").[6[]](https://en.wikipedia.org/wiki/Year_2038_problem#cite_note-6)