EmbeddingGemma 2: an open, lightweight multimodal embedding model
deepmind.google·6d ago
AI Engineering
Lobsters·22d ago·5 min read
Unix Year 2038 problem and the art of underestimating
TL;DR
The Unix Year 2038 problem arises when the 32-bit signed timestamp overflows on January 19, 2038, potentially disrupting systems reliant on time comparisons. This issue parallels the Y2K scare, highlighting the importance of engineering decisions based on measurable constraints.
✦ Why It Matters
Evaluate your systems for 32-bit timestamp dependencies and plan for migration to 64-bit solutions.
Key Takeaways
- Assess your systems for reliance on 32-bit timestamps.
- Upgrade to 64-bit systems to avoid the 2038 overflow issue.
- Check filesystem compatibility with 2038 fixes.
- Understand how different databases manage timestamps.
Full Summary
The Unix Year 2038 problem is a critical issue where the 32-bit signed timestamp, which counts seconds since January 1, 1970, will overflow on January 19, 2038, causing negative values and breaking systems that rely on time comparisons, such as Make. This situation is reminiscent of the Y2K problem, where two-digit year storage was a practical decision based on the technology of the time, like punch cards and early hard disks.
The discussion also touches on the 'DJ10K' problem, which feared that stock tickers would fail when the Dow crossed 10,000 in 1999. Solutions to the 2038 problem include transitioning to 64-bit systems, with Linux kernel 5.6 and later addressing the issue effectively.
However, filesystem support varies, with ext4 and btrfs/xfs being compliant, while older ext3 is not. Different databases handle timestamps in various ways, with Postgres using a 64-bit format valid until the year 294,276, while SQLite lacks a native date type.