The Y2038 issue and Debian 13 (aka: "Trixie")
Below is a story about where Debian 13 (aka: "Trixie") stands regarding the Y2038 issue. In quick summary the Y2038 issue is that time in the current stable Debian release (and to the best of my knowledge all other Linux distributions) stores time as a 32 bit number with the number of seconds since January 1st, 1970 AD. After 03:14:07 UTC on January 19, 2038 you may have Linux systems thinking it is 1970. "Trixie" will be the first Debian release to use 64 bit time. so they will be kicking the issue of running out of time from 2038 to 40,000,000,000 A.D. which should be good enough for most applications :-) . Trixie is in final testing with a final release date not yet announced, so this is in the "coming soon" class... https://lowendbox.com/blog/starting-to-catch-up-linux-finally-addresses-the-... For anyone who is saying to themselves this doesn't matter to me because I run ..."<<Blah>>"... Linux remember that a bunch of other Linux distributions, such as Ubuntu and Raspberry Pi OS are based off of Debian, so this change will ...echo... well outside just Debian.
My bad, I was looking at some old stuff... There is currently a planned release date for "Trixie", so barring some huge strange / bizarre last minute issue "Trixie" will be out August 9th, 2025. On Tue, Jul 29, 2025 at 5:55 PM Colin McGregor <colin.mc151@gmail.com> wrote:
Below is a story about where Debian 13 (aka: "Trixie") stands regarding the Y2038 issue. In quick summary the Y2038 issue is that time in the current stable Debian release (and to the best of my knowledge all other Linux distributions) stores time as a 32 bit number with the number of seconds since January 1st, 1970 AD. After 03:14:07 UTC on January 19, 2038 you may have Linux systems thinking it is 1970.
"Trixie" will be the first Debian release to use 64 bit time. so they will be kicking the issue of running out of time from 2038 to 40,000,000,000 A.D. which should be good enough for most applications :-) . Trixie is in final testing with a final release date not yet announced, so this is in the "coming soon" class...
https://lowendbox.com/blog/starting-to-catch-up-linux-finally-addresses-the-...
For anyone who is saying to themselves this doesn't matter to me because I run ..."<<Blah>>"... Linux remember that a bunch of other Linux distributions, such as Ubuntu and Raspberry Pi OS are based off of Debian, so this change will ...echo... well outside just Debian.
..trixie? Who decides these distribution names? Kare On Tue, 29 Jul 2025, Colin McGregor via Talk wrote:
My bad, I was looking at some old stuff... There is currently a planned release date for "Trixie", so barring some huge strange / bizarre last minute issue "Trixie" will be out August 9th, 2025.
On Tue, Jul 29, 2025 at 5:55 PM Colin McGregor <colin.mc151@gmail.com> wrote:
Below is a story about where Debian 13 (aka: "Trixie") stands regarding the Y2038 issue. In quick summary the Y2038 issue is that time in the current stable Debian release (and to the best of my knowledge all other Linux distributions) stores time as a 32 bit number with the number of seconds since January 1st, 1970 AD. After 03:14:07 UTC on January 19, 2038 you may have Linux systems thinking it is 1970.
"Trixie" will be the first Debian release to use 64 bit time. so they will be kicking the issue of running out of time from 2038 to 40,000,000,000 A.D. which should be good enough for most applications :-) . Trixie is in final testing with a final release date not yet announced, so this is in the "coming soon" class...
https://lowendbox.com/blog/starting-to-catch-up-linux-finally-addresses-the-...
For anyone who is saying to themselves this doesn't matter to me because I run ..."<<Blah>>"... Linux remember that a bunch of other Linux distributions, such as Ubuntu and Raspberry Pi OS are based off of Debian, so this change will ...echo... well outside just Debian.
------------------------------------ Description: GTALUG Talk Unsubscribe via Talk-unsubscribe@lists.gtalug.org Start a new thread: talk@lists.gtalug.org This message archived at https://lists.gtalug.org/archives/list/talk@lists.gtalug.org/message/CCOICKN...
All Debian releases are named after Toy Story characters On Tue, Jul 29, 2025 at 22:01 Karen Lewellen via Talk <talk@lists.gtalug.org> wrote:
..trixie? Who decides these distribution names? Kare
On Tue, 29 Jul 2025, Colin McGregor via Talk wrote:
My bad, I was looking at some old stuff... There is currently a planned release date for "Trixie", so barring some huge strange / bizarre last minute issue "Trixie" will be out August 9th, 2025.
On Tue, Jul 29, 2025 at 5:55 PM Colin McGregor <colin.mc151@gmail.com> wrote:
Below is a story about where Debian 13 (aka: "Trixie") stands regarding the Y2038 issue. In quick summary the Y2038 issue is that time in the current stable Debian release (and to the best of my knowledge all other Linux distributions) stores time as a 32 bit number with the number of seconds since January 1st, 1970 AD. After 03:14:07 UTC on January 19, 2038 you may have Linux systems thinking it is 1970.
"Trixie" will be the first Debian release to use 64 bit time. so they will be kicking the issue of running out of time from 2038 to 40,000,000,000 A.D. which should be good enough for most applications :-) . Trixie is in final testing with a final release date not yet announced, so this is in the "coming soon" class...
https://lowendbox.com/blog/starting-to-catch-up-linux-finally-addresses-the-...
For anyone who is saying to themselves this doesn't matter to me because I run ..."<<Blah>>"... Linux remember that a bunch of other Linux distributions, such as Ubuntu and Raspberry Pi OS are based off of Debian, so this change will ...echo... well outside just Debian.
------------------------------------ Description: GTALUG Talk Unsubscribe via Talk-unsubscribe@lists.gtalug.org Start a new thread: talk@lists.gtalug.org This message archived at https://lists.gtalug.org/archives/list/talk@lists.gtalug.org/message/CCOICKN... ------------------------------------ Description: GTALUG Talk Unsubscribe via Talk-unsubscribe@lists.gtalug.org Start a new thread: talk@lists.gtalug.org This message archived at https://lists.gtalug.org/archives/list/talk@lists.gtalug.org/message/CXMFJDU...
On Tue, Jul 29, 2025 at 05:55:11PM -0400, Colin McGregor via Talk wrote:
Below is a story about where Debian 13 (aka: "Trixie") stands regarding the Y2038 issue. In quick summary the Y2038 issue is that time in the current stable Debian release (and to the best of my knowledge all other Linux distributions) stores time as a 32 bit number with the number of seconds since January 1st, 1970 AD. After 03:14:07 UTC on January 19, 2038 you may have Linux systems thinking it is 1970.
All 32 bit linux distributions. 64 architectures always used 64 bit time and are hence not effected. This is only a concern for 32 bit x86 (which Debian is explicitly NOT changing since they only intend to support it as a legacy compatibility platform running on 64 bit x86 systems) and 32 bit arm. 32 bit powerpc seems essentially dead. Not sure anyone ever really bothered with mips. As they said: "Debian is primarily concerned about the armhf architecture, as it's the 32-bit architecture most likely to still be getting significant usage in new systems over the next decade. But i386, armel, mipsel (and the hppa, hurd-i386, powerpc, m68k and sh4 ports) are also affected. Other 32-bit architectures already use 64-bit time: x32, riscv32, arc and loong32. 64-bit architectures are not affected by the Y2k38 problem, but they are affected by this transition." -- Len Sorensen
Lennart Sorensen via Talk said on Wed, 30 Jul 2025 10:06:59 -0400
On Tue, Jul 29, 2025 at 05:55:11PM -0400, Colin McGregor via Talk wrote:
Below is a story about where Debian 13 (aka: "Trixie") stands regarding the Y2038 issue. In quick summary the Y2038 issue is that time in the current stable Debian release (and to the best of my knowledge all other Linux distributions) stores time as a 32 bit number with the number of seconds since January 1st, 1970 AD. After 03:14:07 UTC on January 19, 2038 you may have Linux systems thinking it is 1970.
All 32 bit linux distributions. 64 architectures always used 64 bit time and are hence not effected.
That's how I've always understood it. 2038 is no problem at all for somebody with a 64 bit computer. This might sound like first world elitism, but the 32 bit Pentium 4 was replaced by the 64 bit Pentium D in 2006. I'm pretty sure that by 1/1/2010 you couldn't buy a 32 bit "personal computer" in laptop or desktop format. So by 2038 a 32 bit computer would be 28 years old. By 2038 one could buy a 64 bit computer that would be 27 years old. 2038? Gimme a break. I worry about climate change. I worry about systemd. I worry about the end of democracy. I worry about H5N1 bird flu. I worry about nuclear war. I worry about Microsoft, Google, Facebook, Amazon, and all the other monopolies increasingly owning our world. Obsolescence of 32 bit computers in 2038? Not so much. By the way, I *AM* very glad Debian/Devuan, Void Linux, and others are keeping 32 bits alive while it's relatively painless to do so. Some of my friends have 32 bit laptops from the days when laptops were rugged and user maintainable. 2038 is still a long way away. SteveT Steve Litt http://444domains.com
On Jul 30, 2025, at 15:33, Steve Litt via Talk <talk@lists.gtalug.org> wrote:
This might sound like first world elitism, but the 32 bit Pentium 4 was replaced by the 64 bit Pentium D in 2006.
All the world’s an Intel box? You might want to look at what AMD was up to around the time Intel was betting on the Itanium architecture.
I worry about climate change. I worry about systemd. I worry about the end of democracy. I worry about H5N1 bird flu. I worry about nuclear war. I worry about Microsoft, Google, Facebook, Amazon, and all the other monopolies increasingly owning our world. Obsolescence of 32 bit computers in 2038? Not so much.
A lot of infrastructure still runs on 32-bit, and Linux gets into some amazing places without bringing along a whole desktop environment. Your computer and phone will be fine, but I worry about wee systems the world takes for granted and forget totally about until that day in January 2038. Anthony
Anthony de Boer via Talk said on Wed, 30 Jul 2025 17:41:31 -0400
On Jul 30, 2025, at 15:33, Steve Litt via Talk <talk@lists.gtalug.org> wrote:
This might sound like first world elitism, but the 32 bit Pentium 4 was replaced by the 64 bit Pentium D in 2006.
All the world’s an Intel box? You might want to look at what AMD was up to around the time Intel was betting on the Itanium architecture.
AMD came out with 64 bit in 2003, which is even more to the point.
I worry about climate change. I worry about systemd. I worry about the end of democracy. I worry about H5N1 bird flu. I worry about nuclear war. I worry about Microsoft, Google, Facebook, Amazon, and all the other monopolies increasingly owning our world. Obsolescence of 32 bit computers in 2038? Not so much.
A lot of infrastructure still runs on 32-bit, and Linux gets into some amazing places without bringing along a whole desktop environment. Your computer and phone will be fine, but I worry about wee systems the world takes for granted and forget totally about until that day in January 2038.
LOL, Y2K all over again. We see it coming and do nothing. We see it coming and do nothing. Then, a year from drop-dead, the sky is falling. Same with the Python 2.7 to 3.x. 10 years of warning, and people are still bitching about that transition. As far as the wee systems, if they aren't important enough to remember, they're not important enough to cause a disaster. I wonder if there's a piece of diagnostic software that could be run on networks to sniff out anything 32 bit. SteveT Steve Litt http://444domains.com
On 7/30/25 18:03, Steve Litt via Talk wrote:
LOL, Y2K all over again. We see it coming and do nothing. We see it coming and do nothing. Then, a year from drop-dead, the sky is falling.
I was at IBM back then and tested all the stuff I was responsible for. I even went in to work on Jan. 1 to make sure everything was still OK. I didn't notice many planes falling out of the sky! 😉
On Jul 30, 2025, at 21:10, James Knott via Talk <talk@lists.gtalug.org> wrote:
I was at IBM back then and tested all the stuff I was responsible for. I even went in to work on Jan. 1 to make sure everything was still OK. I didn't notice many planes falling out of the sky! 😉
I was a voice in the wilderness about Y2K back in the 1980s already, but nobody really cared yet. Late 90s the CEOs heard about it and there was funding to put a big push on and we did a lot of very necessary mitigation and when the day came virtually everything sailed through smoothly. I expect the same to happen next decade as 2038 starts to become visible. Anthony
From: Lennart Sorensen via Talk <talk@lists.gtalug.org>
All 32 bit linux distributions. 64 architectures always used 64 bit time and are hence not effected. This is only a concern for 32 bit x86 (which Debian is explicitly NOT changing since they only intend to support it as a legacy compatibility platform running on 64 bit x86 systems) and 32 bit arm. 32 bit powerpc seems essentially dead. Not sure anyone ever really bothered with mips.
I don't care much about running processes. I care about non-volatile copies of time_t (or whatever the type is called). Is it the case that all non-volatile file systems represent times in some way that extends beyond 2038? If not, which are toast? One guess: 7th Edition Unix Filesystem. Do programs that matter represent times in vulnerable ways in non-volatile storage? Think databases, but not just databases. If they use time_t, the stored representation is already not portable between 32- and 64-bit systems. Or between big-endian and little-endian machines. Why don't I care much about running processes? Because we can update them to use 64-bit time_t and just reboot. Surely there is time to reboot such a system in the next 13 years.
On Wed, Jul 30, 2025 at 06:58:13PM -0400, D. Hugh Redelmeier via Talk wrote:
I don't care much about running processes. I care about non-volatile copies of time_t (or whatever the type is called).
Is it the case that all non-volatile file systems represent times in some way that extends beyond 2038? If not, which are toast? One guess: 7th Edition Unix Filesystem.
Do programs that matter represent times in vulnerable ways in non-volatile storage? Think databases, but not just databases. If they use time_t, the stored representation is already not portable between 32- and 64-bit systems. Or between big-endian and little-endian machines.
Why don't I care much about running processes? Because we can update them to use 64-bit time_t and just reboot. Surely there is time to reboot such a system in the next 13 years.
Good point. ext4 filesystems have 64 bit time support or at least something that goes way beyond 2038. ext2 and ext3 do not. If you are using either of those for /boot you better deal with it sometime in the next 13 years. reiserfs also uses 32 bit time. And SQL has a timestamp problem which needs to be dealt with (I suspect at least some databases have dealt with it already). -- Len Sorensen
On 2025-07-29 17:55, Colin McGregor via Talk wrote:
Below is a story about where Debian 13 (aka: "Trixie") stands regarding the Y2038 issue. In quick summary the Y2038 issue is that time in the current stable Debian release (and to the best of my knowledge all other Linux distributions) stores time as a 32 bit number with the number of seconds since January 1st, 1970 AD.
One thing no one has yet mentioned is that time_t is a signed value. By changing the declaration to unsigned you immediately get another 68 or so years. That would be a short term solution while the time64_t is being introduced. -- Cheers! Kevin. https://www.patreon.com/KevinCozens | "Nerds make the shiny things that | distract the mouth-breathers, and Owner of Elecraft K2 #2172 | that's why we're powerful" #include <disclaimer/favourite> | --Chris Hardwick
On Thu, 31 Jul 2025 at 16:22, Kevin Cozens via Talk <talk@lists.gtalug.org> wrote:
One thing no one has yet mentioned is that time_t is a signed value. By changing the declaration to unsigned you immediately get another 68 or so years.
The problem with doing this is that there may be cases where the value is expected to be negative. For instance, birth dates, where those for years 1970 and higher are positive and those before 1970 are negative. Programs that treated time_t as unsigned wouldn't properly handle such dates before 1970. $ date -d '@-123456789' Tue 01 Feb 1966 09:26:51 PM EST -- Scott
On 2025-07-31 16:40, Scott Allen wrote:
The problem with doing this is that there may be cases where the value is expected to be negative. For instance, birth dates, where those for years 1970 and higher are positive and those before 1970 are negative.
True. The negative use case (I have never seen being used) would also be limited in dates. It could only go back to about 1902. -- Cheers! Kevin. https://www.patreon.com/KevinCozens | "Nerds make the shiny things that | distract the mouth-breathers, and Owner of Elecraft K2 #2172 | that's why we're powerful" #include <disclaimer/favourite> | --Chris Hardwick
On 2025-07-29 17:55, Colin McGregor via Talk wrote:
Below is a story about where Debian 13 (aka: "Trixie") stands regarding the Y2038 issue. In quick summary the Y2038 issue is that time in the current stable Debian release (and to the best of my knowledge all other Linux distributions) stores time as a 32 bit number with the number of seconds since January 1st, 1970 AD.
One thing no one has yet mentioned is that time_t is a signed value. By changing the declaration to unsigned you immediately get another 68 or so years. That would be a short term solution while the time64_t is being introduced. -- Cheers! Kevin. https://www.patreon.com/KevinCozens | "Nerds make the shiny things that | distract the mouth-breathers, and Owner of Elecraft K2 #2172 | that's why we're powerful" #include <disclaimer/favourite> | --Chris Hardwick
On Thu, Jul 31, 2025 at 04:23:01PM -0400, Kevin Cozens via Talk wrote:
One thing no one has yet mentioned is that time_t is a signed value. By changing the declaration to unsigned you immediately get another 68 or so years. That would be a short term solution while the time64_t is being introduced.
But negative values already have an established meaning. If you are going to change it, you change it right. It is making the change that is hard, not the size. -- Len Sorensen
participants (10)
-
Anthony de Boer -
Colin McGregor -
D. Hugh Redelmeier -
James Knott -
Karen Lewellen -
Kevin Cozens -
Lennart Sorensen -
Nick Accad -
Scott Allen -
Steve Litt