The Year 2038 Problem: Why Some 32-Bit Clocks Run Out on Jan. 19, 2038

A signed 32-bit count of seconds since the Unix epoch reaches its maximum, 2,147,483,647, at 03:14:07 Coordinated Universal Time (UTC) on Tuesday, Jan. 19, 2038. The Open Group, which publishes the Portable Operating System Interface (POSIX) specification, defines the epoch as “The time zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC).” This explainer gives the limit moment in several time zones, a countdown, and the 2106 limit of an unsigned counter. Our printable checklist is built from the same facts.

What happens at 03:14:07 UTC on Jan. 19, 2038?

The Open Group describes “seconds since the Epoch” as “A value that approximates the number of seconds that have elapsed since the Epoch.” Software that keeps that number in a signed 32-bit integer can count up to 2,147,483,647. The Linux kernel documentation puts the consequence in one line: “the tv_sec member overflows in year 2038 on 32-bit architectures.”

We computed the two moments around the limit with a short script and checked them twice:

Counter value	Moment in UTC
2,147,483,647 (largest signed 32-bit value)	03:14:07, Tuesday, Jan. 19, 2038
-2,147,483,648 (the next second, if the counter wraps)	20:45:52, Friday, Dec. 13, 1901
4,294,967,295 (largest unsigned 32-bit value)	06:28:15, Sunday, Feb. 7, 2106

The wrapped value is the smallest signed 32-bit number, so a clock that wraps jumps back about 136 years, to 1901.

What time is the limit moment in your time zone?

The moment is fixed. The clock reading and even the calendar day depend on the zone. In January, U.S. zones are on standard time.

Zone	Local time of the limit moment
Eastern Standard Time (EST), UTC-5	10:14:07 p.m., Monday, Jan. 18, 2038
Central Standard Time (CST), UTC-6	9:14:07 p.m., Monday, Jan. 18, 2038
Mountain Standard Time (MST), UTC-7	8:14:07 p.m., Monday, Jan. 18, 2038
Pacific Standard Time (PST), UTC-8	7:14:07 p.m., Monday, Jan. 18, 2038
Greenwich Mean Time (GMT), UTC+0	3:14:07 a.m., Tuesday, Jan. 19, 2038
Central European Time (CET), UTC+1	4:14:07 a.m., Tuesday, Jan. 19, 2038
India Standard Time (IST), UTC+5:30	8:44:07 a.m., Tuesday, Jan. 19, 2038
Japan Standard Time (JST), UTC+9	12:14:07 p.m., Tuesday, Jan. 19, 2038

All conversions are our calculation from UTC. For how the “Z” and offsets in a timestamp work, see our guide to International Organization for Standardization (ISO) 8601 dates and times.

Why does Microsoft say January 18, 2038?

Microsoft Learn says: “We don’t recommend _USE_32BIT_TIME_T because your application may fail after January 18, 2038.” The page does not say which clock it means. Our inference, not Microsoft’s statement, is that this matches the local-time view: 03:14:07 UTC on Jan. 19 is still the evening of Jan. 18 in the Eastern, Central, Mountain and Pacific zones in the table above.

Microsoft also says its default time type “is equivalent to __time64_t by default, which is a 64-bit signed integer that supports dates through 23:59:59, December 31, 3000 UTC.”

How many days are left until Jan. 19, 2038?

From Jan. 1, 2027 to Jan. 19, 2038 is 4,036 days. As of Nov. 4, 2026, the calendar date is 4,094 days away. Both counts are our calculation and include every leap day in between; the leap year rules explain which years those are.

What have operating systems said about 64-bit time?

These are the statements we found from the projects themselves:

• glibc. The 2.34 release notes say it will “Add support for 64-bit time_t on configurations like x86 where time_t is traditionally 32-bit.” It adds: “Although time_t still defaults to 32-bit on these configurations, this default may change in future versions.” It is “enabled with the _TIME_BITS preprocessor macro set to 64.”
• glibc 2.40. The 2.40 release notes for struct lastlog, utmp and utmpx says: “This allows these fields to store timestamps beyond the year 2038, until the year 2106.” That is the unsigned limit in the table above.
• Debian. The Debian Wiki says that for the application binary interface (ABI), “it was decided to do an in-architecture ABI transition for all 32-bit architectures except i386 and hurd-i386,” and that “The actual transition began on February 27th, 2024.” The page was last modified Aug. 10, 2025.
• Linux kernel. In a Jan. 29, 2020 pull request, developer Arnd Bergmann wrote that Linux 5.6 “should be the first release that can serve as a base for a 32-bit system designed to run beyond year 2038.” The Register reported it on Jan. 30, 2020. That is the developer’s stated goal for the release, not a statement that the problem is solved everywhere.

We did not find a statement from the Cybersecurity and Infrastructure Security Agency (CISA) or the National Institute of Standards and Technology (NIST) on this date, and we do not name any product that will fail.

What should you check before Jan. 19, 2038?

The limit matters wherever software stores a time as one 32-bit number. The printable lists the places to look, and the first three steps are these:

1. Make a list of devices that keep their own clock and note each model and age.
2. Ask each maker whether the software stores time in 64 bits, and write down the answer.
3. Test a date after Jan. 19, 2038 in anything that holds long-term dates, such as a lease, loan or warranty end date.

The sheet also prints the epoch definition, Microsoft’s warning and the glibc 2.40 line, each with its source. Mark the day on a printable yearly calendar or in the January printable calendars when you plan the test.