Conversation

Notices

1. Embed this notice
   Mark ☑️ (mhjohnson@noauthority.social)'s status on Wednesday, 07-May-2025 12:20:06 JST Mark ☑️

   Okay, this is a strange bug in Linux (or Debian?)

   https://www.jwz.org/blog/2025/05/y2232-bug/

   Where you cannot set a date later than
   2232-04-18 16:47:15
   or you will get an error. The magic number is
   0x1ED5D7403

   WTAF indeed. (first comment)

   The second comment suggests you use google to search for
   year 2232 bug
   I did that and got an AI explanation for the cicada broods from last year. WTAF!!

   • Embed this notice
     djsumdog (djsumdog@djsumdog.com)'s status on Wednesday, 07-May-2025 12:20:05 JST djsumdog

     in reply to

     I thought that had been fixed a long time ago. Most systems measure time in "seconds since the epoch," and in the Linux world, that's the number of seconds since January 1st, 1970. So the number of seconds on a 32-bit int overflows in 2032. The easiest way past that is it use a 64-bit int for the time_t type. I haven't kept up with the issues for a while, but I thought all modern glibc, musl implementations had already switched to the 64-bit time struct available from the clock in modern Linux kernels.

   • Embed this notice
     djsumdog (djsumdog@djsumdog.com)'s status on Wednesday, 07-May-2025 12:35:57 JST djsumdog

     in reply to

     • Daniel Stevens
     ah interesting. Not all the blog comments show up without Javascript. Interesting the system time in is is seems to be in an unsigned long long? That does make sense since you want ns precision for the system clock and you don't want IEEE floating point madness for time.
     
     So I guess the plan is to switch to 128-bit ns precision time later down the road? x86_64 and ARM already have 128-bit registers for special cases (SSE instructions, vectorization, loop unrolling), but I guess they don't have general purpose ones yet.
   • Embed this notice
     Daniel Stevens (eris@p.enes.lv)'s status on Wednesday, 07-May-2025 12:35:58 JST Daniel Stevens

     in reply to

     • djsumdog
     This one is nanoseconds, 64 bit, and it's reported from the kernel. See the third comment in the linked post.
     
     CC: @mhjohnson@noauthority.social
     
     djsumdog likes this.