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]

FAT usually includes the very similar FAT12, FAT16 and FAT32, but not exFAT (which shares nothing with the usual FAT format except the three letters in its name and its origin within Microsoft). But the directory entry format for FAT12/16/32 is identical (with the exception of the reuse of another area for the two high bytes of the first cluster number), and all store years in the seven-bit format.

In any event FAT16 are not really going away. You cannot have a FAT32 volume of less than about 32MB, and exposing the storage on small devices as a flash drive is reasonably popular (and many of those have far less than 32MB of flash). Basically it allows a firmware update just by plugging the device into any USB port, and copying the new firmware to the “drive.” Even the internal flash on many current cameras is smaller than that (obviously before you add a flash card). True it's hard to find a "real" flash drive these days that's much smaller than 2GB, but those aren't the only uses. Rwessel (talk) 08:50, 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]

I removed the bold from "year 32,768 problem" etc, on the grounds that such bolding violated WP:MOSBOLD. NapoliRoma restored the bolds with the comment that "the bolded terms are redirect targets", presumably complying with WP:R#PLA. However I assert that the reader will not be "astonished", because the terms mentioned are exactly what the redirect name was, and thus the bold is not necessary, as per the H2O example on WP:R#PLA. Mitch Ames (talk) 12:45, 16 February 2011 (UTC)[reply]

I was indeed thinking of WP:R#PLA. I'm not sure what you're saying here, since if you follow the guidance of WP:R#PLA and bold the redirected term, the term mentioned will indeed be exactly what the redirect name was. This seems to me to confirm the guidance in WP:R#PLA, not make it unnecessary.

So looking at WP:R#PLA, I'm confused about what the distinction is between the two examples: Tiptree/Sheldon and H2O. Why is Sheldon bolded and H2O not? Regards, NapoliRoma (talk) 22:26, 17 February 2011 (UTC)[reply]

It appears that the guideline's author is assuming that someone looking for "H2O" already knows that it is water. Whereas someone looking for Alice Sheldon might not realise that James Tiptree was the same person. I'm not so sure that the first assumption is valid. Mitch Ames (talk) 13:01, 18 February 2011 (UTC)[reply]

I believe Days 32,768 and 65,536 and Years 32,768 and 65,536 should remain as one topic, they are both relying on the sane faults and are very similar. I have not time to edit right now, before I do in the future feel free to object. Yup ^{(Talk? - Contribs?)} 13:18, 14 June 2011 (UTC)[reply]