Author Topic: Year 2038 problem  (Read 335 times)


  • Member
  • *****
  • Posts: 10439
  • Assembler is fun ;-)
    • MasmBasic
Year 2038 problem
« on: March 08, 2020, 01:02:22 PM »
Is the year 2038 problem a real problem, or is it just a hoax in the computer science community?
A 32-bit signed binary integer can be incremented up to  231−1=2147483647 , so a representation of time using this structure would overflow on the early morning hours (UTC) of 19 January 2038, hence the name of the problem.

A lot of things in computing rely on accurate timekeeping and representation of time, and there are still a number of things that need to be updated in order to fix this:

  • Network time protocol (NTP) uses a 32-bit seconds field and a 32-bit fractions-of-seconds field, although the epoch begins on a different date (1 January 1900), so the hypothetical deadline would instead occur in 2036. Some solutions to this impending deadline have been proposed, but a solution has yet to be agreed upon.
  • Some (most?) file systems and file formats still represent file modification, access, and creation times with 32 bits.
  • DVB and ATSC television standards use 32 bits to represent the time, but this cannot be changed easily because doing so would break compatibility with legacy receivers.
  • A number of 32-bit versions of operating systems still run with 32-bit representations of time. Most 64-bit flavors of operating systems (Windows, modern versions of macOS, Linux, various flavors of BSD) have transitioned to using 64-bit representations, or are currently undergoing the transition process.

So in short, the problem is most certainly real, and if left unsolved, there can be potentially costly issues

Not true for Windows NT:

include \masm32\MasmBasic\        ; download
  PrintLine fDate$(TimeSF("01.01.1899"))       ; 01.01.3799 (error)
  PrintLine fDate$(TimeSF("01.01.1900"))       ; 01.01.1900
  PrintLine fDate$(TimeSF("01.01.2038"))       ; 01.01.2038
  PrintLine fDate$(TimeSF("01.01.30827"))      ; 01.01.30827
  PrintLine fDate$(TimeSF("01.01.30828"))      ; 01.01.30827 (error)

Only the last one, btw, returns "parameter not correct" :cool:


  • Administrator
  • Member
  • ******
  • Posts: 7423
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: Year 2038 problem
« Reply #1 on: March 08, 2020, 04:34:45 PM »
The year 2000 bug was supposed to usher in the end of the world but we are still here 20 years later. It will be fixed by then when we have 256 bit OS versions.  :skrewy:
hutch at movsd dot com    :biggrin:  :skrewy:


  • Member
  • *****
  • Posts: 2253
Re: Year 2038 problem
« Reply #2 on: March 08, 2020, 05:42:42 PM »
Scientists say: politicians need to subsidize research into this catastrophic problem.
Some scientists say: electronics will start fires in 2038.
Still waiting for Greta and AOC for better solutions.
Creative coders use backward thinking techniques as a strategy.


  • Member
  • *****
  • Posts: 1313
  • building nextdoor
Re: Year 2038 problem
« Reply #3 on: March 28, 2020, 06:05:56 AM »
By this time the Ai rules the world and humans need to adjust to their way of counting,that's why the world of the matrix looks like it's placed in 1970+
With old cars,old computers with only monochrome screens  :skrewy:
Hope that will be the future otherwise everyone must hurry to convert your huge 32bit code to 64 bit or worse before it totally breaks 2038 :tongue: :badgrin:
Quote from Flashdance
Nick  :  When you give up your dream, you die
*wears a flameproof asbestos suit*
Gone serverside programming p:  :D
I love assembly,because its legal to write
princess:lea eax,luke