Jump to content

Wikipedia:Articles for deletion/Year 2038 problem

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Lionel Elie Mamane (talk | contribs) at 08:25, 6 May 2022 (→‎Year 2038 problem: strong keep vote). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Year 2038 problem

Year 2038 problem (edit | talk | history | protect | delete | links | watch | logs | views) – (View log | edits since nomination)
(Find sources: Google (books · news · scholar · free images · WP refs· FENS · JSTOR · TWL)

Highly speculative. It makes sense to think that this is fixed way before 2038. Nononsense101 (talk) 17:29, 2 May 2022 (UTC)[reply]

Keep. Firstly, there may be some legacy systems / software libraries in use where this will still be a problem in 2038. Secondly, this problem already manifests when 32-bit systems try to refer to times later than 2038 (see the 'early problems' section). Thirdly, even if this is widely fixed before 2038, the term 'Year 2038 problem' still refers to a problem with the 32-bit time system. It still exists even if it does not manifest. For example, imagine trying to explain why times are stored as 64-bit integers to a colleague: "You could use 32-bit, but then you can't cover a very wide range of times. Go and look up 'Year 2038 problem' for details." Harrybraviner (talk) 12:41, 3 May 2022 (UTC)[reply]
  • Keep This article is more relevant and possibly even more potential to be destructive than even the Y2K problem. Urbanracer34 (talk) 17:38, 2 May 2022 (UTC)[reply]
  • Keep Even though this is a speculative article about an event in 16 years, there has been significant coverage about the effects of the end of 32-bit UNIX time. While this issue will (hopefully) be resolved before it comes to pass, it is a significant possible future event. Balon Greyjoy (talk) 17:47, 2 May 2022 (UTC)[reply]
  • Comment Struck; double-voting isn't allowed and was effectively given already by your nomination. Nate (chatter) 01:34, 3 May 2022 (UTC)[reply]
  • Keep: A quick google search found significant coverage 1, 2, 3, 4, 5. Sourcing is not the greatest but the article from The Guardian and the sources I found should be enough to pass GNG. It's also worth noting that WP:Crystal states that "Individual scheduled or expected future events should be included only if the event is notable and almost certain to take place. Dates are not definite until the event actually takes place, as even otherwise-notable events can be cancelled or postponed at the last minute by a major incident. If preparation for the event is not already in progress, speculation about it must be well documented." Since this is technically an event and has been well documented, WP:CRYSTAL does not apply. ColinBear (talk - contributions) 21:26, 2 May 2022 (UTC)[reply]
  • Keep Even if every system is fixed by 1/19/38, the work to do so is just as notable, and will affect multiple computer operating systems. Nate (chatter) 01:33, 3 May 2022 (UTC)[reply]
  • Strongly keep: it might be seen as too far in the future, except it isn't. Y2K38 bugs have struck important systems such as AOLserver (which was a popular server) in 2006 (https://www.mail-archive.com/aolserver@listserv.aol.com/msg09820.html), and there are documented systems (like actuarial programs used by insurance companies) where dates beyond 2038 are actually being calculated now. Additionally, this discusses why it happens in 2038/01/19 and not another date (like how the truncation of centuries and millennia in dates due to necessary space-saving in 1960s lead to Year 2000 problem). - 2001:4453:581:9400:E82C:91AA:B31B:7FD (talk) 09:29, 3 May 2022 (UTC)[reply]
  • keep I work in IT as a programmer - this is something that I am already encountering and coding for. Although the dating system is outdated, it is still used. As has been suggested, lots of people are working on fixes and they will be implemented by 2038, however, which systems will be missed? There can be tiny but critical systems that nobody thought of. Vespasianvs (talk) 09:35, 3 May 2022 (UTC)[reply]
  • Keep (and honestly this could at least be a WP:SNOWCLOSE). It is happening now so not speculative and even if it had been completely fixed yesterday, it still is a notable topic with more than sufficient coverage in WP:RSs. Skynxnex (talk) 14:37, 3 May 2022 (UTC)[reply]
  • Strong Keep Echoing what others have said, basically. This isn't a WP:CRYSTAL situation any more than List of future astronomical events is. This is a set of problems that will, with mathematical certainty, occur unless a way is found to mitigate them - and even if such a mitigation is found, even the search for those solutions is already noteworthy enough for inclusion now, as it has been widely covered in reputable media sources. Sleddog116 (talk) 15:50, 3 May 2022 (UTC)[reply]
  • Speedy keep Obviously notable topic. Cranloa12n / talk / contribs / 20:45, 3 May 2022 (UTC)[reply]
  • Speedy keep Obviously notable topic, see also Year 2000 problem. ~ Matthewrb Talk to me · Changes I've made 21:50, 4 May 2022 (UTC)[reply]
  • Speedy keep No reason to delete this, very notable and is verified to happen. See you in 16 years. Pyraminxsolver (talk) 02:07, 5 May 2022 (UTC)[reply]
  • Keep I don't like it when knowledge is erased, period. This article contains interesting and meaningful, and at that pertinent, content, and like other people have said is worth keeping. Kiril kovachev (talk) 22:06, 5 May 2022 (UTC)[reply]
  • Speedy keep Even if the problem were to be fixed before this date, it would still meet WP:N as there is currently significant coverage. Additionally, as per ColinBear, WP:CRYSTAL does not apply. GoodCrossing (talk) 22:38, 5 May 2022 (UTC)[reply]
  • Strong Keep As many others have explained, not a WP:CRYSTAL situation; serious and notable subject in Unix circles. The fact whether these will, or will not, be fixed "in time" is of no concern to the decision to keep or delete; as long as it is a notable thing, it has its place on Wikipedia. Lionel Elie Mamane (talk)