Talk:Time formatting and storage bugs
|WikiProject Computer science|
- 1 Merge from various articles
- 2 FAT filesystem date format (year 2108)
- 3 Daylight Savings Time
- 4 Year 292,277,026,296 problem
- 5 13 bit GPS
- 6 2044
- 7 Years 2127 and 2255
- 8 bolding of "year 32,768 problem" etc
- 9 Adding of some of the topics together
- 10 Other species of date bug
- 11 time zone for 2042
- 12 Suggested Year 2042 section split
- 13 libshadow and Tuesday, October 17, 2243
Merge from various articles
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)
- 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)
FAT filesystem date format (year 2108)
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)
- The ultimate limit is 2107-15-31 31:63:62, which works out as 2108-04-01 08:04:02 (UTC ignoring leap seconds?). 220.127.116.11 (talk) 22:56, 22 January 2010 (UTC)
- 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)
Daylight Savings Time
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)
Year 292,277,026,296 problem
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)
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 18.104.22.168 (talk) 14:29, 2 March 2010 (UTC)
13 bit GPS
- 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)
- (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). 22.214.171.124 (talk) 11:54, 22 March 2010 (UTC)
- 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)
- 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 126.96.36.199; I now am usually 188.8.131.52 (talk) 22:22, 24 January 2011 (UTC).
Years 2127 and 2255
Article has "The SPD EEPROM on modern computer memory modules contains a single-byte 2000-based year-of-manufacture code at offset 0x5D, 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. 184.108.40.206 (talk) 11:37, 22 March 2010 (UTC)
bolding of "year 32,768 problem" etc
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)
- 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)
- 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)
Adding of some of the topics together
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)
- Bear in mind that although the storage problem is identical, the results my differ, because days is an offset, whereas year is an absolute value. So a year value of -1 might be displayed as "-1", which would generally be self-evidently wrong, but a day value of -1 might appear (for example if it is an offset from 1 January 1900) as 31 December 1899, which is not so obviously wrong, being a perfectly valid date. Mitch Ames (talk) 05:41, 16 June 2011 (UTC)
Other species of date bug
The bugs currently in the article all relate to the capacity of a storage field. Perhaps there should be a page on date bugs in general, linking of course to this page.
Examples include :
- Daycount peculiarities originating with wrongly taking 1900 to have been a Leap Year.
- Peculiar effects with fractional dates before 1899-12-30, stored as negative reals, because of the way div and mod work.
- Easter date errors, due to misunderstandings, link to Computus
- Mis-implementations : Safari 5.1 is often a day out for non-current days, seemingly due to including a three in the Leap Year coding - see in http://www.merlyn.demon.co.uk/js-datex.htm.
- Ignoring the effects of offset from GMT and/or or seasonal changes
time zone for 2042
Suggested Year 2042 section split
- Oppose - unless there's a meaningful expansion of content, I see no real reason to split this. A redirect from Year 2042 Problem might be reasonable. Rwessel (talk) 10:21, 9 December 2012 (UTC)
- I'd point out that several other sections were created as merges of insufficiently notable articles (Year 32,768 problem, Year 65,536 problem, Year 292,277,026,596 problem and Year 170,141,183,460,469,231,731,687,303,715,884,105,727 problem). For completeness, I'll mention that Year 10,000 problem has survived several rounds at AfD. Also 2042 Problem already exists as a redirect, for consistency with the others, another at Year 2042 problem makes sense. Rwessel (talk) 10:35, 9 December 2012 (UTC)
- Oppose and I have proposed a merge at Year 10,000 problem#Suggested Merge. Better to have one good, comprehensive article than several low-content articles that make the same points over and over. --Guy Macon (talk) 15:37, 9 December 2012 (UTC)
- I don't disagree, but there appear to have been four failed attempts to have Year 10,000 problem deleted or merged already. My desire to stick my foot in that is minimal.
In any event, it doesn't look like you got the merge proposal into that page, in case you're wanting to pursue it. Rwessel (talk) 05:26, 10 December 2012 (UTC)
libshadow and Tuesday, October 17, 2243
The libshadow is using six digits that are days to represent various expiry fields. The beginning of time is at January 1st, 1970. The Oct 17, 2243 is exactly one million days since the beginning of time _and_ the time of counter wrap. Whether this interests anyone, even as curiosity, is another question.