The Y2286 problem
I wonder how many things are going to break on November 20, 2286.
Context: That is when the UNIX epoch rolls over from 9999999999 to 10000000000.
Normally base-10 numbers aren’t considered a problem when it comes to computers, but there are certainly systems out there that are assuming that UNIX epoch times converted to a string sort lexically1. And on those systems, November 20, 2286 at 17:46:40 (GMT) will (lexically) sort lower than November 20, 2286 at 17:46:39.
And this is absolutely going to be a really subtle issue; at least in the current day and age, it’s pretty common for strings and integers to be used interchangeably and there only being a problem when mathematical operations are involved. Some languages even go so far as to implicitly convert when comparing them2 So I can imagine plenty of circumstances where something is using the UNIX epoch time for something (say, a filename), then using a lexical sort or comparison to perform various find or delete operations. (For example, using the newest version of a file, or deleting files older than a certain reference time, or the like.)
Anyway, for this reason (among others) it’s best to use the ISO-8601 timestamp format for any long-term comparison methods, as it doesn’t run into any potential sorting problems3 until January 1, 10000. And if humans are even around that long, good luck to them!
There are two ways of comparing strings that contain numbers: lexically (i.e. the dictionary order, comparing the characters from left to right), and numerically (comparing their lengths before comparing the characters from left to right, with extra fiddliness for a value starting with
false, which is a WTF of its own but for different reasons. ↩
Except for the one little thing where comparing dates with datetimes is correct lexically, but not numerically. ↩
Before commenting, please read the comment policy.
Avatars provided via Libravatar