2697: Y2K and 2038 - Revision history

172.71.147.63 at 05:14, 22 October 2024

2024-10-22T05:14:59Z

172.71.146.59 at 05:11, 22 October 2024

2024-10-22T05:11:10Z

172.71.147.100 at 05:06, 22 October 2024

2024-10-22T05:06:12Z

172.71.147.147: /* Explanation */

2024-10-22T05:05:10Z

‎Explanation

172.70.90.145: Undo revision 346876 by 172.71.146.188 (talk) Correct correction.

2024-07-22T11:01:19Z

Undo revision 346876 by 172.71.146.188 (talk) Correct correction.

172.71.146.188: Undo revision 312627 by ConscriptGlossary (talk) Vandalism

2024-07-22T10:14:43Z

Undo revision 312627 by ConscriptGlossary (talk) Vandalism

ChristmasGospel: Edit by ClassicalGames

2023-05-09T06:22:08Z

Edit by ClassicalGames

Xurkitree10: /* Transcript */

2023-04-22T13:05:42Z

‎Transcript

Beret: /* Explanation */ Resolved "incomplete" tag

2022-11-30T06:36:59Z

‎Explanation: Resolved "incomplete" tag

172.70.210.243: /* Explanation */ esoterica to end of similar paragraph

2022-11-17T07:28:45Z

‎Explanation: esoterica to end of similar paragraph

@@ Line 21: / Line 21: @@
 This comic assumes that the 38 years between Y2K and Y2038 should be split evenly between recovering from Y2K and preparing for Y2038. That would put the split point in 2019. The caption points out that it's now, in 2022, well past that demarcation line, so everyone should have completed their "Y2K recovery" and begun preparing for year 2038. It is highly unlikely that there are more than a very few consequential older systems that still suffer from the Y2K bug, as systems built to operate this millennium handle years after 1999 correctly. The topic of whether or not Y2K was actually as big of a problem as it was made out to be remains hotly debated. The main arguments falling into the general camps of "nothing bad happened, Y2K would have overwhelmingly been an inconvenience rather than a problem" vs. "very little happened ''only'' because of the massive effort put into prevention". It is unlikely that there will ever be a conclusive answer to the question, with the truth probably being somewhere in between those two extremes. Whatever the answer to that question may be, the reaction to Y2K did result in a significant push towards, and raise in public awareness of, clean and futureproofed code.
-The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes. Doing this may seem complicated to new software developers, but recompiling with a larger size of integers was a normal solution for the Y2K bug among engineers of [[Randall]]'s generation, who learned to code when computer memory space was still at a premium. For example, in most implementations of the C language, the data type that represents 32-bit integers is called "long", while a 16-bit integer is a "short". C actually does allow programmers to declare a 33-bit integer ("long long:33"), but they're slow unless running on custom hardware that supports such a type natively (which no hardware currently does). Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability, but it is a far less efficient use of resources than upgrading to the widely available and supported 64-bit Unix time replacement format and software compatibility libraries.
+The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes. Doing this may seem complicated to new software developers, but recompiling with a larger size of integers was a normal solution for the Y2K bug among engineers of [[Randall]]'s generation, who learned to code when computer memory space was still at a premium. For example, in most implementations of the C language, the data type that represents 32-bit integers is called "long", while a 16-bit integer is a "short". C actually does allow programmers to declare a 33-bit integer ("long long:33"), but they're really just treated as 64-bit numbers that get truncated when stored, and would be slow unless running on custom hardware that supports such a type natively (which no hardware currently does). Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability, but it is a far less efficient use of resources than upgrading to the widely available and supported 64-bit Unix time replacement format and software compatibility libraries.
 ==Transcript==

@@ Line 21: / Line 21: @@
 This comic assumes that the 38 years between Y2K and Y2038 should be split evenly between recovering from Y2K and preparing for Y2038. That would put the split point in 2019. The caption points out that it's now, in 2022, well past that demarcation line, so everyone should have completed their "Y2K recovery" and begun preparing for year 2038. It is highly unlikely that there are more than a very few consequential older systems that still suffer from the Y2K bug, as systems built to operate this millennium handle years after 1999 correctly. The topic of whether or not Y2K was actually as big of a problem as it was made out to be remains hotly debated. The main arguments falling into the general camps of "nothing bad happened, Y2K would have overwhelmingly been an inconvenience rather than a problem" vs. "very little happened ''only'' because of the massive effort put into prevention". It is unlikely that there will ever be a conclusive answer to the question, with the truth probably being somewhere in between those two extremes. Whatever the answer to that question may be, the reaction to Y2K did result in a significant push towards, and raise in public awareness of, clean and futureproofed code.
-The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes. Doing this may seem complicated to new software developers, but recompiling with a larger size of integers was a normal solution for the Y2K bug among engineers of [[Randall]]'s generation, who learned to code when computer memory space was still at a premium. For example, in most implementations of the C language, the data type that represents 32-bit integers is called "long", while a 16-bit integer is a "short". In principle a language could support 33-bit integers ("longer"?), but unless it was running on computer hardware that supported such a type directly, it would be slow. Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability, but it is a far less efficient use of resources than upgrading to the widely available and supported 64-bit Unix time replacement format and software compatibility libraries.
+The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes. Doing this may seem complicated to new software developers, but recompiling with a larger size of integers was a normal solution for the Y2K bug among engineers of [[Randall]]'s generation, who learned to code when computer memory space was still at a premium. For example, in most implementations of the C language, the data type that represents 32-bit integers is called "long", while a 16-bit integer is a "short". C actually does allow programmers to declare a 33-bit integer ("long long:33"), but they're slow unless running on custom hardware that supports such a type natively (which no hardware currently does). Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability, but it is a far less efficient use of resources than upgrading to the widely available and supported 64-bit Unix time replacement format and software compatibility libraries.
 ==Transcript==

@@ Line 21: / Line 21: @@
 This comic assumes that the 38 years between Y2K and Y2038 should be split evenly between recovering from Y2K and preparing for Y2038. That would put the split point in 2019. The caption points out that it's now, in 2022, well past that demarcation line, so everyone should have completed their "Y2K recovery" and begun preparing for year 2038. It is highly unlikely that there are more than a very few consequential older systems that still suffer from the Y2K bug, as systems built to operate this millennium handle years after 1999 correctly. The topic of whether or not Y2K was actually as big of a problem as it was made out to be remains hotly debated. The main arguments falling into the general camps of "nothing bad happened, Y2K would have overwhelmingly been an inconvenience rather than a problem" vs. "very little happened ''only'' because of the massive effort put into prevention". It is unlikely that there will ever be a conclusive answer to the question, with the truth probably being somewhere in between those two extremes. Whatever the answer to that question may be, the reaction to Y2K did result in a significant push towards, and raise in public awareness of, clean and futureproofed code.
-The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes. Doing this may seem complicated to new software developers, but recompiling with a larger size of integers was a normal solution for the Y2K bug among engineers of [[Randall]]'s generation, who learned to code when computer memory space was still at a premium. For example, in most implementations of the C language, the data type that represents 32-bit integers is called "long", while a 16-bit integer is a "short". In principle a language could support 33-bit integers, but unless it was running on computer hardware that supported such a type directly, it would be slow. Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability, but it is a far less efficient use of resources than upgrading to the widely available and supported 64-bit Unix time replacement format and software compatibility libraries.
+The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes. Doing this may seem complicated to new software developers, but recompiling with a larger size of integers was a normal solution for the Y2K bug among engineers of [[Randall]]'s generation, who learned to code when computer memory space was still at a premium. For example, in most implementations of the C language, the data type that represents 32-bit integers is called "long", while a 16-bit integer is a "short". In principle a language could support 33-bit integers ("longer"?), but unless it was running on computer hardware that supported such a type directly, it would be slow. Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability, but it is a far less efficient use of resources than upgrading to the widely available and supported 64-bit Unix time replacement format and software compatibility libraries.
 ==Transcript==

@@ Line 21: / Line 21: @@
 This comic assumes that the 38 years between Y2K and Y2038 should be split evenly between recovering from Y2K and preparing for Y2038. That would put the split point in 2019. The caption points out that it's now, in 2022, well past that demarcation line, so everyone should have completed their "Y2K recovery" and begun preparing for year 2038. It is highly unlikely that there are more than a very few consequential older systems that still suffer from the Y2K bug, as systems built to operate this millennium handle years after 1999 correctly. The topic of whether or not Y2K was actually as big of a problem as it was made out to be remains hotly debated. The main arguments falling into the general camps of "nothing bad happened, Y2K would have overwhelmingly been an inconvenience rather than a problem" vs. "very little happened ''only'' because of the massive effort put into prevention". It is unlikely that there will ever be a conclusive answer to the question, with the truth probably being somewhere in between those two extremes. Whatever the answer to that question may be, the reaction to Y2K did result in a significant push towards, and raise in public awareness of, clean and futureproofed code.
-The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes. Doing this may seem complicated to new software developers, but recompiling with a larger size of integers was a normal solution for the Y2K bug among engineers of [[Randall]]'s generation, who learned to code when computer memory space was still at a premium. Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability, but it is a far less efficient use of resources than upgrading to the widely available and supported 64-bit Unix time replacement format and software compatibility libraries.
+The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes. Doing this may seem complicated to new software developers, but recompiling with a larger size of integers was a normal solution for the Y2K bug among engineers of [[Randall]]'s generation, who learned to code when computer memory space was still at a premium. For example, in most implementations of the C language, the data type that represents 32-bit integers is called "long", while a 16-bit integer is a "short". In principle a language could support 33-bit integers, but unless it was running on computer hardware that supported such a type directly, it would be slow. Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability, but it is a far less efficient use of resources than upgrading to the widely available and supported 64-bit Unix time replacement format and software compatibility libraries.
 ==Transcript==

@@ Line 15: / Line 15: @@
 The Y2K bug, or more formally, the {{w|year 2000 problem}}, was the computer errors caused by two digit software representations of calendar years incorrectly handling the year 2000, such as by treating it as 1900 or 19100. The {{w|year 2038 problem}} is a similar issue with timestamps in {{w|Unix time}} format, which will overflow their {{w|Signed number representations|signed}} 32-bit binary representation on January 19, 2038.
-While initial estimates were that the Y2K problem would require about half a trillion dollars to address, there was widespread recognition of its potential severity several years in advance. Concerted efforts among organizations including computer and software manufacturers and their corporate and government users reflected unprecedented cooperation, testing, and enhancement of affected systems costing substantially less than the early estimates. On New Year's Day 2000, few major errors actually occurred. Those that did usually did not disrupt essential processes or cause serious problems, and the few of them that did were usually addressed in days to weeks. The software code reviews involved allowed correcting other errors and providing various enhancements which often made up at least in part for the the cost of correcting the date bug.
+While initial estimates were that the Y2K problem would require about half a trillion dollars to address, there was widespread recognition of its potential severity several years in advance. Concerted efforts among organizations including computer and software manufacturers and their corporate and government users reflected unprecedented cooperation, testing, and enhancement of affected systems costing substantially less than the early estimates. On New Year's Day 2000, few major errors actually occurred. Those that did usually did not disrupt essential processes or cause serious problems, and the few of them that did were usually addressed in days to weeks. The software code reviews involved allowed correcting other errors and providing various enhancements which often made up at least in part for the cost of correcting the date bug.
 It is unclear whether the 2038 problem will be addressed as effectively in time, but documented experience with the Y2K bug and increased software modularity and access to source code has allowed many otherwise vulnerable systems to already upgrade to wider timestamp and date formats, so there is reason to believe that it may be even less consequential and expensive. The 2038 problem has been previously mentioned in [[607: 2038]] and [[887: Future Timeline]].

← Older revision		Revision as of 13:05, 22 April 2023
Line 24:		Line 24:

	==Transcript==		==Transcript==
−	~~{{incomplete transcript\|Do NOT delete this tag too soon.}}~~
−
	[A timeline rectangle with 37 short dividing lines between the two ends, defining it into 38 minor sections, with the label "2000" above, associated with the leftmost edge, "2038" associated with the rightmost edge and "2019" directly over the centermost division that starts the section which covers that year, which is also extended to form a dotted line divided the whole height of the timeline into two equal 19-section halves. The left half has the label "Recovering from the Y2K bug" and the right half is labeled "Preparing for the 2038 bug". A triangular arrowhead labeled "Now" is also above indicating a rough position most of the way through the section that would represent the year 2022.]		[A timeline rectangle with 37 short dividing lines between the two ends, defining it into 38 minor sections, with the label "2000" above, associated with the leftmost edge, "2038" associated with the rightmost edge and "2019" directly over the centermost division that starts the section which covers that year, which is also extended to form a dotted line divided the whole height of the timeline into two equal 19-section halves. The left half has the label "Recovering from the Y2K bug" and the right half is labeled "Preparing for the 2038 bug". A triangular arrowhead labeled "Now" is also above indicating a rough position most of the way through the section that would represent the year 2022.]

← Older revision		Revision as of 06:36, 30 November 2022
Line 10:		Line 10:

	==Explanation==		==Explanation==
−	~~{{incomplete\|Created by a Y2K-BRICKED BOT (MADE JAN 1, 1970). Do NOT delete this tag too soon.}}~~

	[[File:Year 2038 problem.gif\|thumb\|An animation of the 2038 bug in action. The {{w\|integer overflow}} error occurs at 03:14:08 UTC on 19 January 2038.]]		[[File:Year 2038 problem.gif\|thumb\|An animation of the 2038 bug in action. The {{w\|integer overflow}} error occurs at 03:14:08 UTC on 19 January 2038.]]