[Bnshsysjab]

2037 is a potential overflow, I believe. I imagine only pre 2000 systems would likely be affected.

[xyzzy_plugh]

Only pre 2000 systems? I'd love to live in your dream world.

Last I looked, plenty of fixes were trickling into the kernel in 2014. I wonder how many of those made the long backport to stable.

Let alone all those 2.6 kernels (and older!) in the wild. And all your 32-bit devices are probably gonna have a bad time.

[marvy]

Kernel will hopefully be ready; user space is another story.

[roland35]

There may be a lot of embedded systems affected though! Most embedded C uses 32 bit integers, especially for the Real Time Clock peripherals!

[ncmncm]

But what self-respecting embedded-system coder would use a signed 32-bit value?

Various libc choices in use probably have time_t signed.

[aaronmdjones]

And pre-2000 filesystems, like FAT. As well as a lot of filesystems developed after that, which also use 32-bit file creation/modification timestamps.

[mkl]

2038 is when signed 32-bit ints overflow. That's only running out of binary digits though, not decimal like the event under discussion.

  In [1]: import datetime
  In [2]: datetime.datetime.utcfromtimestamp(2**31)
  Out[2]: datetime.datetime(2038, 1, 19, 3, 14, 8)

[ncmncm]

That is just when signed 32 bits rolls over. Unsigned takes us all the way to 2106.

Nervous nellies worried about rollover, and insisting we switch to 64-bit timestamps everywhere, are a nuisance. You can keep one 64-bit epoch, such as boot time or most recent foreign attack on NYC, and as many 32-bit offsets from that as you like, and always be able to get a 64-bit time whenever you need it. Most often you only need a difference, so one epoch is as good as any, and you can work purely in 32 bits.

Pcap format is good until 2106 assuming the 1970 epoch. A bit of one of the now-unused header fields could be repurposed to indicate another.