This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
Per Wikipedia:Articles for deletion/Year 32,768 problem, I've created this page as a merge of
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)
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)
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)
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)
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)
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)
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 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)
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 :
If such a page exists or is created, this article should link to it conspicuously. 94.30.84.71 ( talk) 12:10, 24 September 2011 (UTC)
For IBM mainframes, P.Ops. specifies "ETR time" (External Time Reference) that's 10 seconds behind TAI. Not R ( talk) 22:02, 14 September 2012 (UTC)
user:Tyranitar Man has suggesting splitting the section Time formatting and storage bugs#Year 2042 into its own article.
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.
Sami Kerola ( talk) 11:27, 2 January 2013 (UTC)
[1] 212.203.0.138 ( talk) 06:20, 15 August 2014 (UTC)
I recently changed the section heading "Problems" that aren't problems
to "Problems"
, but my edit
was reverted. I tried to change it because (a) The word "aren't" is a
contraction which should be avoided, (b) The heading contradicts itself and (c) It sounds unencyclopedic (which I know is an overused term, but here I mean "doesn't sound professional"). The use of
scare quotes is a bit weird and I would suggest, rather than what I originally changed it to, the heading Theoretical issues
for the section. Since my edit has been
reverted, I'd like to hear
NapoliRoma's opinion and anyone else's. Do you agree the heading name should be changed? Do you like my suggestion of "Theoretical issues" or have your own to suggest, or think it's fine the way it is? —
Bilorv
(talk)
(c)
(e)
15:56, 5 February 2015 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on Time formatting and storage bugs. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— cyberbot II Talk to my owner:Online 01:02, 2 July 2016 (UTC)
Do you think there should be a mention somewhere about [RFC 2550] - "Y10K and Beyond"? Although this is an "April 1st" parody RFC, it proposes a solution that, if implemented, actually does solve all of these "time formatting and storage bugs", at the expense of quite a bit of (unnecessary for most applications) software complexity. Shamino ( talk) 16:16, 17 May 2018 (UTC)
Twitter uses a distributed ID system named "Snowflake", which consists of a 41-bit timestamp and 22 bits of other data. Twitter uses 2006-03-21 20:50:14.000 UTC as their epoch, so it will roll over on 2075-11-26 at 12:37:49.552 UTC. Discord uses a similar ID generation scheme with 42-bit timestamps (using the 64th bit of the ID for an explicit purpose) and an epoch of 2015-01-01 00:00:00.000 UTC, so their IDs will roll over on 2154-05-15 at 07:35:11.104 UTC. Maybe these should be included? — Preceding unsigned comment added by Nameless6144 ( talk • contribs)
Parallelism is usually a good idea.
... this happened for the first time at 23:59:47 on Saturday 21 August 1999, the second time at 23:59:42 UTC on 6 April 2019 ...
One has the weekday, the other doesn't; one has UTC, the other doesn't. — MaxEnt 20:17, 16 April 2019 (UTC)
In 9999 some systray icons be unclickable, and calendar randomly crashes.
In 20000, Windows 10 adds 1 to the year.
In 24613 Windows 10 stops working. See this video.
Note: At the 2080 problem, 1996 isn't the single solution, as one can use 2024 or 2052 in lieu of 2080.
Alfa-ketosav ( talk) 11:46, 30 April 2019 (UTC)
According to this book, Microsoft Outlook stores the date 1 Jan 4501 instead of Null. It seems some other software (for example Google Picasa) use this date as an empty value (see the EXIF for this file, for example). Razvan Socol ( talk) 13:25, 18 August 2019 (UTC)
An editor has asked for a discussion to address the redirect 32,768. Please participate in the redirect discussion if you wish to do so. 14.207.205.207 ( talk) 04:02, 10 January 2020 (UTC)
We might need higher resolution in future applications. ¿Why not start with the internal clock counting PlanckTimeUnits. We would have to use a 256-bit internal representation for the time. As a signed representation, the clock could handle takes out to 1*10^26 years in the future (I used only 1 significant figure because this is a ridiculously large number where the exact number of years is unimportant (all that one must understand is that it is big enough)). After we choose the 0-Time, we are set for the next 10^26 years with no need to mess with it. I propose that 00,000-01-01T00:00:00Z HE be the 0-Time. — Preceding unsigned comment added by 2601:643:C002:2830:D504:E45C:4C6D:894E ( talk) 18:58, 8 August 2020 (UTC)
The section of the article on 2262 is about storing time as nanoseconds since 1970 in signed 64-bit, which overflows on 11 April 2162. It lists C++ chrono::system_clock as having this problem, with a reference to https://en.cppreference.com/w/cpp/chrono/system_clock. But this reference does not talk about storage as nanoseconds in signed 64-bit. So I've flagged that ref as {{Failed verification}}. Does anyone have a better reference? netjeff ( talk) 02:27, 12 March 2021 (UTC)
We note at the end of 2049, two digit email header years will fail. [2] Jidanni ( talk) 13:27, 20 July 2021 (UTC)
A discussion is taking place to address the redirect 10,783,118,943,836,478,994,022,445,751,223. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 September 8#10,783,118,943,836,478,994,022,445,751,223 until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Hog Farm Talk 05:19, 8 September 2021 (UTC)
Services like Microsoft Exchange (on-premesis version) are apparently having problems because some related services use a YYMMDDhhmm format for versioning ( screenshot). This is seemingly parsed as a 32-bit signed integer, which has a maximum value of 2,147,483,647 but 2022 dates become 2,2xx,xxx,xxx.
It's not a "time formatting and storage bug" in that it's not a Y2K-like bug. But there was a suggestion for Snowflake limits, which seem more closely related to this kind of "date as a version" problem.
Should this be included in this list? — Preceding unsigned comment added by IBBoard ( talk • contribs) 11:38, 1 January 2022 (UTC)
Sorry I didn't see your entry here before adding it to the page (I'm new to editing wikipedia). For me this is clearly a "time formatting and storage bug" with the storage overflowing being 32 bit signed integers holding YYMMDDhhmm formatted strings by decimal conversion. The specific Microsoft bug might be versioning related, but underlying is a date overflow. Flocular ( talk) 13:06, 1 January 2022 (UTC)
The following comment was added in a recent edit by user:207.81.187.41:
<!--or was it yymmdd0001 regardless of the value of HHMM?-->
The greatest 32-bit signed integer is, in hexadecimal notation, 7FFF FFFF. This is 2,147,483,647 in decimal. The last minute of 2021 would be written 2112312359, which is less than this, and the first minute of 2022 would be written 2201010000 which is greater than this. So it is essential that the hour and minute digits be included in order to cause the overflow. I will remove the HTML comment. Jc3s5h ( talk) 16:57, 3 January 2022 (UTC)
Isn't Roman numerals another cause of Year 4000 problem. Because largest Roman numeral is MMMCMXCIX or 3999. 89.236.252.20 ( talk) 12:20, 7 April 2022 (UTC)
The proleptic Gregorian 1 January 9999 BC was a Monday (Julian 19 March 10000 BC). 31 December 9999, a Gregorian date, will be a Friday and "2958465" is its number. 189.69.67.242 ( talk) 20:20, 16 September 2022 (UTC)
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)
Yep, those were mostly wrong. Now (hopefully) corrected.
Rwessel (
talk)
20:03, 9 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 211.27.152.145 ( talk) 14:29, 2 March 2010 (UTC)
Yesterday, I added a [citation needed] to the section about humanity being dead by this date, and it was reverted. Perhaps that wasn't the correct way to go about it, as I am not an experienced Wikipedia editor, but I take issue with the way that it's worded. All 3 other points (earth, the sun, and the universe) have links to the section about the topic of their speculated final fate on their own pages, but the section about humanity lacks this, as if this was self-evident. Willytor ( talk) 17:42, 28 December 2022 (UTC)
This article uses CE in some places and AD in others. Is that okay or should it be edited to consistently use one or the other? 184.21.204.5 ( talk) 02:40, 31 December 2022 (UTC)
The redirect 292,277,026,296 has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 June 5 § 292,277,026,296 until a consensus is reached. GeoffreyT2000 ( talk) 01:42, 5 June 2023 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
Per Wikipedia:Articles for deletion/Year 32,768 problem, I've created this page as a merge of
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)
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)
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)
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)
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)
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)
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 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)
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 :
If such a page exists or is created, this article should link to it conspicuously. 94.30.84.71 ( talk) 12:10, 24 September 2011 (UTC)
For IBM mainframes, P.Ops. specifies "ETR time" (External Time Reference) that's 10 seconds behind TAI. Not R ( talk) 22:02, 14 September 2012 (UTC)
user:Tyranitar Man has suggesting splitting the section Time formatting and storage bugs#Year 2042 into its own article.
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.
Sami Kerola ( talk) 11:27, 2 January 2013 (UTC)
[1] 212.203.0.138 ( talk) 06:20, 15 August 2014 (UTC)
I recently changed the section heading "Problems" that aren't problems
to "Problems"
, but my edit
was reverted. I tried to change it because (a) The word "aren't" is a
contraction which should be avoided, (b) The heading contradicts itself and (c) It sounds unencyclopedic (which I know is an overused term, but here I mean "doesn't sound professional"). The use of
scare quotes is a bit weird and I would suggest, rather than what I originally changed it to, the heading Theoretical issues
for the section. Since my edit has been
reverted, I'd like to hear
NapoliRoma's opinion and anyone else's. Do you agree the heading name should be changed? Do you like my suggestion of "Theoretical issues" or have your own to suggest, or think it's fine the way it is? —
Bilorv
(talk)
(c)
(e)
15:56, 5 February 2015 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on Time formatting and storage bugs. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— cyberbot II Talk to my owner:Online 01:02, 2 July 2016 (UTC)
Do you think there should be a mention somewhere about [RFC 2550] - "Y10K and Beyond"? Although this is an "April 1st" parody RFC, it proposes a solution that, if implemented, actually does solve all of these "time formatting and storage bugs", at the expense of quite a bit of (unnecessary for most applications) software complexity. Shamino ( talk) 16:16, 17 May 2018 (UTC)
Twitter uses a distributed ID system named "Snowflake", which consists of a 41-bit timestamp and 22 bits of other data. Twitter uses 2006-03-21 20:50:14.000 UTC as their epoch, so it will roll over on 2075-11-26 at 12:37:49.552 UTC. Discord uses a similar ID generation scheme with 42-bit timestamps (using the 64th bit of the ID for an explicit purpose) and an epoch of 2015-01-01 00:00:00.000 UTC, so their IDs will roll over on 2154-05-15 at 07:35:11.104 UTC. Maybe these should be included? — Preceding unsigned comment added by Nameless6144 ( talk • contribs)
Parallelism is usually a good idea.
... this happened for the first time at 23:59:47 on Saturday 21 August 1999, the second time at 23:59:42 UTC on 6 April 2019 ...
One has the weekday, the other doesn't; one has UTC, the other doesn't. — MaxEnt 20:17, 16 April 2019 (UTC)
In 9999 some systray icons be unclickable, and calendar randomly crashes.
In 20000, Windows 10 adds 1 to the year.
In 24613 Windows 10 stops working. See this video.
Note: At the 2080 problem, 1996 isn't the single solution, as one can use 2024 or 2052 in lieu of 2080.
Alfa-ketosav ( talk) 11:46, 30 April 2019 (UTC)
According to this book, Microsoft Outlook stores the date 1 Jan 4501 instead of Null. It seems some other software (for example Google Picasa) use this date as an empty value (see the EXIF for this file, for example). Razvan Socol ( talk) 13:25, 18 August 2019 (UTC)
An editor has asked for a discussion to address the redirect 32,768. Please participate in the redirect discussion if you wish to do so. 14.207.205.207 ( talk) 04:02, 10 January 2020 (UTC)
We might need higher resolution in future applications. ¿Why not start with the internal clock counting PlanckTimeUnits. We would have to use a 256-bit internal representation for the time. As a signed representation, the clock could handle takes out to 1*10^26 years in the future (I used only 1 significant figure because this is a ridiculously large number where the exact number of years is unimportant (all that one must understand is that it is big enough)). After we choose the 0-Time, we are set for the next 10^26 years with no need to mess with it. I propose that 00,000-01-01T00:00:00Z HE be the 0-Time. — Preceding unsigned comment added by 2601:643:C002:2830:D504:E45C:4C6D:894E ( talk) 18:58, 8 August 2020 (UTC)
The section of the article on 2262 is about storing time as nanoseconds since 1970 in signed 64-bit, which overflows on 11 April 2162. It lists C++ chrono::system_clock as having this problem, with a reference to https://en.cppreference.com/w/cpp/chrono/system_clock. But this reference does not talk about storage as nanoseconds in signed 64-bit. So I've flagged that ref as {{Failed verification}}. Does anyone have a better reference? netjeff ( talk) 02:27, 12 March 2021 (UTC)
We note at the end of 2049, two digit email header years will fail. [2] Jidanni ( talk) 13:27, 20 July 2021 (UTC)
A discussion is taking place to address the redirect 10,783,118,943,836,478,994,022,445,751,223. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 September 8#10,783,118,943,836,478,994,022,445,751,223 until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Hog Farm Talk 05:19, 8 September 2021 (UTC)
Services like Microsoft Exchange (on-premesis version) are apparently having problems because some related services use a YYMMDDhhmm format for versioning ( screenshot). This is seemingly parsed as a 32-bit signed integer, which has a maximum value of 2,147,483,647 but 2022 dates become 2,2xx,xxx,xxx.
It's not a "time formatting and storage bug" in that it's not a Y2K-like bug. But there was a suggestion for Snowflake limits, which seem more closely related to this kind of "date as a version" problem.
Should this be included in this list? — Preceding unsigned comment added by IBBoard ( talk • contribs) 11:38, 1 January 2022 (UTC)
Sorry I didn't see your entry here before adding it to the page (I'm new to editing wikipedia). For me this is clearly a "time formatting and storage bug" with the storage overflowing being 32 bit signed integers holding YYMMDDhhmm formatted strings by decimal conversion. The specific Microsoft bug might be versioning related, but underlying is a date overflow. Flocular ( talk) 13:06, 1 January 2022 (UTC)
The following comment was added in a recent edit by user:207.81.187.41:
<!--or was it yymmdd0001 regardless of the value of HHMM?-->
The greatest 32-bit signed integer is, in hexadecimal notation, 7FFF FFFF. This is 2,147,483,647 in decimal. The last minute of 2021 would be written 2112312359, which is less than this, and the first minute of 2022 would be written 2201010000 which is greater than this. So it is essential that the hour and minute digits be included in order to cause the overflow. I will remove the HTML comment. Jc3s5h ( talk) 16:57, 3 January 2022 (UTC)
Isn't Roman numerals another cause of Year 4000 problem. Because largest Roman numeral is MMMCMXCIX or 3999. 89.236.252.20 ( talk) 12:20, 7 April 2022 (UTC)
The proleptic Gregorian 1 January 9999 BC was a Monday (Julian 19 March 10000 BC). 31 December 9999, a Gregorian date, will be a Friday and "2958465" is its number. 189.69.67.242 ( talk) 20:20, 16 September 2022 (UTC)
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)
Yep, those were mostly wrong. Now (hopefully) corrected.
Rwessel (
talk)
20:03, 9 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 211.27.152.145 ( talk) 14:29, 2 March 2010 (UTC)
Yesterday, I added a [citation needed] to the section about humanity being dead by this date, and it was reverted. Perhaps that wasn't the correct way to go about it, as I am not an experienced Wikipedia editor, but I take issue with the way that it's worded. All 3 other points (earth, the sun, and the universe) have links to the section about the topic of their speculated final fate on their own pages, but the section about humanity lacks this, as if this was self-evident. Willytor ( talk) 17:42, 28 December 2022 (UTC)
This article uses CE in some places and AD in others. Is that okay or should it be edited to consistently use one or the other? 184.21.204.5 ( talk) 02:40, 31 December 2022 (UTC)
The redirect 292,277,026,296 has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 June 5 § 292,277,026,296 until a consensus is reached. GeoffreyT2000 ( talk) 01:42, 5 June 2023 (UTC)