Bit by Bit is a weekly column focusing on technical advances each and every week across multiple spaces. My name is Adam Conway, and I've been covering tech and following the cutting-edge for a decade. If there's something you're interested in and would like to see covered, you can reach out to me at adam@xda-developers.com.
✕ Remove Ads
Have you ever seen a software or service say something happened on the 1st of January, 1970? This is the Unix epoch or POSIX time, which a lot of services use as a fixed point to count non-leap seconds. In Windows, Microsoft uses January 1st, 1601, and Macs used January 1st, 1904, before switching to the Unix epoch alongside the switch from HFS to APFS. However, Apple's implementation means that your MacBook or iPhone will roll the date back around to January 1st, 1970 once we hit the year 2554.
Apple used to have a much bigger problem
Your MacBook's previous limitation was only in 2038
✕ Remove Ads
With the transition to APFS (Apple File System), Macs adopted the Unix epoch (starting from January 1, 1970) for their timekeeping, aligning with most Unix-based systems. However, the APFS implementation in macOS means your Mac will only be able to represent dates up to February 6, 2554. After that, the date will loop back around to January 1, 1970. While this is a far-off issue, it sets an upper limit for dates in Apple's current file system and means that a lot of things will likely break on your Mac come that date.
✕ Remove Ads
Of course, it's pretty unlikely that anyone reading this article will live to that year, and if Apple still exists by then and is still releasing new MacBooks and iPhones, chances are they'll have come up with a solution. However, this problem used to be significantly worse. The previous limitation of MacBooks and iPhones used to be February 6, 2040, and this was only changed with APFS when Apple changed over to 64-bit timekeeping. Apple uses 64-bit unsigned integer nanoseconds, which is why the limitation is as low as it is, comparatively.
This limitation is also largely exclusive to Apple. While 32-bit Unix machines will face problems come January 19th, 2038, 64-bit Unix machines can count to 2^64 seconds. This is 1.8446744e+19 seconds or 584,542,046,091 years. Depending on whether the machine measures in seconds, milliseconds, or nanoseconds changes how many years it can count to, and counting in nanoseconds is why Apple's limitation is "only" the year 2554.
✕ Remove Ads
What about Windows? Do Apple users actually have a problem?
Windows uses a "tick" system
With Windows, Microsoft can represent times from January 1st, 1601 to approximately the year 30,828. This is because Windows counts time in 100-nanosecond intervals, with the only downside of this method being that you can't count in nanoseconds on Windows-based machines. However, this level of precision is rarely needed, and 100-nanosecond ticks are more than good enough for most users.
✕ Remove Ads
However, Apple users don't actually have anything to worry about. Apple will almost certainly update their operating systems to support a much wider date range, and probably years and years in advance of 2554 if that even is a problem by then. We're talking about a date more than 500 years away, so it's obviously significantly hyperbolic to claim that it's a problem in any way, shape, or form.
With that said, epochs in general are an interesting way to keep track of time in computers, and different operating systems do it in different ways. Apple's is technically the most accurate way to do it, but it has the "downside" of ending sooner than the rest.
If you're reading this in the year 2554 and you have an old iPhone or Mac, then I guess you should probably back up your data.
✕ Remove Ads