Time Unassessed

This article is within the scope of WikiProject Time, a collaborative effort to improve the coverage of Time on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TimeWikipedia:WikiProject TimeTemplate:WikiProject TimeTime ??? This article has not yet received a rating on Wikipedia's content assessment scale. ??? This article has not yet received a rating on the project's importance scale.

Per Wikipedia:Articles for deletion/Year 32,768 problem, I've created this page as a merge of

• Year 32,768 problem
• Year 65,536 problem
• Year 292,277,026,596 problem
• Year 170,141,183,460,469,231,731,687,303,715,884,105,727 problem

As of tonight, this is very rough, and mainly consists of copying the raw content from each of these articles. This is not the intended final result; I have plans for more edits in the near future to make this more coherent and less redundant, but I wanted to get the original content in the edit history.--NapoliRoma (talk) 06:40, 21 January 2008 (UTC)[reply]

Grouping under a single heading (more descriptive than 'Y2K and Y2K again') all the problems caused by using two digits to represent a year would be a good idea. Then Year 1900 problem and Year 2070 problem could also be merged into this article. Only Year 2000 problem really has sufficient unique content to warrant a separate article. —Safalra (talk) 12:25, 27 January 2008 (UTC)[reply]

The FAT filesystem date format (also used internally in ZIP files etc.) only goes until December 31st, 2107 (though some Microsoft operating systems reportedly only supported dates up through 2099)... AnonMoos (talk) 22:59, 26 March 2008 (UTC)[reply]

The ultimate limit is 2107-15-31 31:63:62, which works out as 2108-04-01 08:04:02 (UTC ignoring leap seconds?). 82.163.24.100 (talk) 22:56, 22 January 2010 (UTC)[reply]

So shouldn't this be in the article? I'd do it myself, but I'd rather someone with more authoritative knowledge do so (preferably with a cite, of course...)--NapoliRoma (talk) 17:26, 29 January 2011 (UTC)[reply]

Done. Rwessel (talk) 07:27, 31 January 2011 (UTC)[reply]

Does this problem include the FAT32 filesystem? The article FAT32 hints that it is so, should be mentioned here. The FAT filesystem, limited to 2 GB per partition is being phased out already. --BIL (talk) 08:24, 31 January 2011 (UTC)[reply]

I just spotted Year 2007 problem, which would seem to me to be a specific instance of the more generic problem of systems with hard-coded DST routines; this would seem to be another candidate to merge here.--NapoliRoma (talk) 15:06, 22 July 2008 (UTC)[reply]

I'm assuming there's a particular reason that it is presumed 2^63 divided by the number of seconds in a year would equal 292,277,026,296. Something just doesn't seem right when below the statement that 2^(16 - 1) would become negative while 2^(64 - 1) would return to zero. Mechamind90 (talk) 20:27, 8 October 2009 (UTC)[reply]

Yep, those were mostly wrong. Now (hopefully) corrected. Rwessel (talk) 20:03, 9 October 2009 (UTC)[reply]

Okay, so what about the statement that it's past the end of the universe? Some red dwarfs currently in existence will still be shining then, if they aren't mined out first. —Preceding unsigned comment added by 211.27.152.145 (talk) 14:29, 2 March 2010 (UTC)[reply]

The 13-bit GPS rollover seems to me to be Tuesday 2136-12-25 (to be adjusted for ignoring leap seconds) : if confirmed, that might as well be given. 82.163.24.100 (talk) 23:01, 22 January 2010 (UTC)[reply]

If the DOS datestamp is treated as a signed value, it rolls over at 2043/44. 82.163.24.100 (talk) 23:05, 22 January 2010 (UTC)[reply]

Yes, but it's not, it's an unsigned 7-bit bitfield within each directory entry. It will overflow in 2108. — Loadmaster (talk) 05:36, 26 January 2010 (UTC)[reply]

(Italic to differentiate between above and below) Wrong. The year is seven bits unsigned; the date stamp is 32 bits YYYYYYYMMMMDDDDD hhhhhmmmmmmsssss. The stamp will overflow on reaching 2108; but, if it is treated as signed (inevitable in systems with longint but not longword) the year will apparently go from 1980+63 to 1980-64 on reaching 2044. Direct 32-bit longint comparisons across 2043/44 will be in error; if longword is unavailable, one should use longint ones on (datestamp XOR $80000000). 82.163.24.100 (talk) 11:54, 22 March 2010 (UTC)[reply]

Which is discussed in the section "FAT filesystem date format (year 2108)" above. Even today, we do not use the FAT/DOS file system so much anymore, so it is no a big problem I assume. --BIL (talk) 10:13, 26 January 2010 (UTC)[reply]

(Italic to differentiate between above and below) Programs written for MSDOS will run unchanged in WinXP using COMMAND.COM or CMD.EXE, with a post-FAT file system. Their view of directory entries is as it always was, with one 32-bit datestamp. 82.163.24.100 (talk) 11:54, 22 March 2010 (UTC)[reply]

Actually FAT is used everywhere. Flash drives used in cameras, MP3 players, camcorders, USB memory sticks, etc. are almost all formatted FAT. The one place it's not used very much anymore is on hard drives (or on SSDs) - although even there it's hardly uncommon - many people who boot more than one OS have a FAT partition to ease moving data between those OS's. FAT support is basically universal, and thus is heavily used. FWIW, the basic ZIP file format uses the same two byte time and date formats (with the seven bit year) as does FAT, and I'm sure there are other places too. As to APIs, both MS-DOS (Int 21h / 4eh) and Win32/Win64 (via FileTimeToDosDateTime()) present the pair of two-byte fields in the format with a seven bit year. Given that it's explicitly a seven bit field in all these places (and thus requiring special handling from any code that needs to process it), I think the odds of someone mistakenly interpreting it as a *signed* seven bit field are slim. Rwessel (talk) 21:45, 26 January 2010 (UTC)[reply]

Remember that the 7-bit field is at the MS end of a YMD word and the MS end of a YMDhms longword. To compare dates for magnitude, one compares the word; to compare date/times, the longword. The problem will appear if, in either case, signed arithmetic is used; and that is a reasonably easy mistake to make. Especially if the language has longint but not longword (the fix is to XOR with 0x8000 or 0x8000000 before comparison; several times a day I use code containing that fix). I was usually 82.163.24.100; I now am usually 94.30.84.71 (talk) 22:22, 24 January 2011 (UTC).[reply]

Article has "The SPD EEPROM on modern computer memory modules contains a single-byte 2000-based year-of-manufacture code at offset 0x5D[5][6], which, depending on signed/unsigned interpretation, will wraparound on Dec 31 2127 or Dec 31 2255. Due to the 18-24 month generational cycle in computer technology this should not be a problem.". That is badly written. There is no problem in 2127 & 2255 (cf. Y2K), so Subject should be "Years 2128 and 2256". There is no wrap on Dec 31st; it occurs immediately after Dec 31st. 82.163.24.100 (talk) 11:37, 22 March 2010 (UTC)[reply]