[WirelessGigabit]

> 64-bit architectures are not affected by the y2k38 problem, but they are affected by this transition.

I read the article with my limited knowledge and I couldn't find an explanation for this statement. Can someone elaborate?

[mikepavone]

On Linux at the kernel level, time_t was historically defined as a 'long'. Since Linux is LP64 this automatically became 64-bit on 64-bit architectures.

[zinekeller]

I would initially assume that the problem is due to compatibility concerns (like NFS3 requiring 32-bit timestamps), but is instead a rather Debian-specific problem:

  Or we can do library transitions for the set of all libraries that reference time_t in their ABI; this is a bit more work for everyone in the short term because it will impact testing migration across all archs rather than being isolated to a single port, but it’s on the order of 500 library packages which is comparable to other ABI transitions we’ve done in the past (e.g.  ldbl https://lists.debian.org/debian-devel/2007/05/msg01173.html).

[TacticalCoder]

> but is instead a rather Debian-specific problem

It is Debian specific because Debian is one of the rare distro which keeps supporting 32 bit systems. The others don't even bother, it's all 64 bit now, where the year 2038 problem doesn't exist at all.

[Denvercoder9]

See my comment elsewhere in this discussion: https://news.ycombinator.com/item?id=40264502.

[bun_terminator]

(here stood something wrong because I've been working with 32bit code for too long recently)

[TonyTrapp]

> but in general time_t is commonly an int32 type - doesn't matter what OS it compiles on

Maybe 20 years ago, but these days you cannot make such a generalization. For example, VC++ uses a 64-bit time_t even in 32-bit builds unless you explicitly define _USE_32BIT_TIME_T. on 64-bit builds, a 32-bit time_t would be an illegal configuration that won't even build.

[CamperBob2]

In Win32 builds, it's been necessary to request legacy 32-bit time_t structures explicitly with _USE_32BIT_TIME_T for many years, for what that's worth. 64-bit time_t has been the standard for a while.

[bun_terminator]

ow, a stark reminder that I've worked with out 32bit code for far too long