Talk:Year 2038 problem/Archive 1

message: Is it just me, or do we have a lot of redundancy in this article? A rewrite is in order, methinks. Ambush Commander 19:34, Jun 25, 2005 (UTC)
: I second the idea of a rewrite. I am going to try to take care of it in the coming days... --jonasaurus 21:46, 12 July 2005 (UTC)
thread_title:  Redundancy 

message: Times beyond this moment will be represented internally as a negative number, which may cause some programs to fail, since they will see these times not as being in 2038 but rather in 1901.
Should that be 1970? I thought that the rollover would go back to the initial system condition. Captainmax 06:20, 18 July 2005 (UTC)
replies: text: Nope definately 1901 because the variable is signed. And will go back 2^31 seconds ( ~68 years ) when it overflows ( IIRC overflow is the term ) ( adding 1 to a 32 bit unsigned int which is already 2^32-1 will overflow to 0 ). However i think windows uses an unsigned int so will goto 1970. See also Integer (computer science) --2mcm 01:09, 20 July 2005 (UTC)
replies: text:  This depends on the implementation. If the library strips the high bit, it will roll back to 1970. If it doesn't, it might revert to 1901. I can also imagine an implementation which would produce negative hours after 2038. If time_t is treated as an unsigned, the "year 2038 problem" should not happen at all until 2106. Note that C and POSIX themselves only say that time_t should be an arithmetic type. Doesn't even have to be an integer type. squell 16:38, 26 August 2005 (UTC)
thread_title:  1901? 

message: Okay, I make two cases against the argument "Years aren't formatted with commas." First of all, technically, they are when they're really big (see History of the World). Second of all, for all practical purposes, it is a better idea to leave the commas in, so the reader knows it's roughly 300 billion years in the future, and not 292277026596 (which is harder to decipher). — Ambush Commander(Talk) 01:47, August 15, 2005 (UTC)
: One could format it in the non-American centric way using spaces? Maybe that would be a good compromise?
::Generally, Wikipedia allows lots of leeway in choosing between British and American usage, but according to the manual of style, we should be using commas in numbers. — Ambush Commander(Talk) 01:17, September 6, 2005 (UTC)
::: Commas in numbers for digit seperation isn't American centric. It's English native-centric. The vast majority of native English speakers whether from the US, UK, Australia, India, NZ, etc use commas (or spaces sometimes) to seperate numbers, and periods for the decimal point. Non English native Europeans generally use commas for the decimal point and periods for seperation (or spaces). For Asians and Arabs, it's somewhat more variable. In the case of those that were colonised, they generally follow whoever colonised them (last). For example, the English-native 'standard' is used in Malay Nil Einne 04:31, 29 December 2005 (UTC)
replies: text: You can't round 292,277,026,596 to 300 billion, if thats what your proposing, when the exact year is central and necesary to the article. Philc TECI 11:33, 24 June 2006 (UTC)
thread_title:  Commas in the Year 292,277,026,596 Problem 

message: I love the fact that this article says "the earth is not expected to last beyond 5 billion years more (as of the year 2005)." I've made a note to myself to come back in the year 1,000,002,005 and change this to "4 billion". --OpenToppedBus - Talk to the driver 13:25, 6 December 2005 (UTC)
replies: text: Hmm, I just removed that reference because I felt it didn't really add to the 'gag' which was already there. Feel free to put it back though (somewhere between now and the year 1,000,002,005). squell 17:27, 6 December 2005 (UTC)
thread_title: As of 2005

message: Rounding 292,471,208,678 up to '300 billion' as if 7 billion, 429 million years were insignficant is just wrong. (Bjorn Tipling 07:09, 28 December 2005 (UTC)
replies: text: I didn't do it but it is fairly insignificant. It doesn't matter if it is 7 billion years or 700 billions years if the percentage is small. The percentage error is only around ~2.5% so it isn't really a significant error. However, generally speaking, when you round things, it's wise to keep all digits significant IMHO. So it would be better to round it to 292 billion rather then 300 billion. Nil Einne 04:35, 29 December 2005 (UTC)
replies: text:  Yeah that's much better. I'd still like to see anyone who'd say 2 billion years are insignficant hold their breath that long. (Bjorn Tipling 05:26, 29 December 2005 (UTC)
replies: text:  Well, all of us will do it, eventually ;) —Preceding unsigned comment added by 150.254.143.180 (talk • contribs) 00:33, 26 Mar 2006 (UTC)

text:  So we can change your DNA around 2.5%, and it won't matter, because it's not really a significant error? Neat. Let me know how life as a chimp is. ;-) krikkert (Talk) 10:17, 26 February 2007 (UTC)
thread_title:  Rounding up over 7 billion years 

message: The 128-bit solution does extends the problem date to December 31, 17,014,118,346,046,923,173,168,730,371,588,410 hence being much farther away than the problem with the 62-bit solution. ftp://ftp.rfc-editor.org/in-notes/rfc2550.txt I've added that to the article. Voortle 01:31, 1 August 2006 (UTC)
replies: text: Maybe we should talk about this.  Why isn't a 64 bit solution enough?  ~a (user • talk • contribs) 01:33, 1 August 2006 (UTC)

text: Fyi, RFC 2550 (no link) works.  ~a (user • talk • contribs) 01:38, 1 August 2006 (UTC)
replies: text:  The 64-bit solution is enough for right now, as we're so very far from the year 292,471,208,678. The 64-bit solution would be able to fix the year 2038 problem. I just thought that the more powerful solution was worth mentioning in the article. Voortle 01:42, 1 August 2006 (UTC)
replies: text:  Why does WP need to talk about the 128 bit solution?  In the year 292,471,208,678 we'll have gone through millions of generations and we'll have switched solar systems either hundreds of times or thousands of times (see Life cycle of a star#Maturity).  Also, why did you remove "is meant to be humourous and" from the comment in the article?  ~a (user • talk • contribs) 01:51, 1 August 2006 (UTC)
replies: text:  One may similarly ask, why does Wikipedia need to talk about the year 10,000 problem? In the year 10,000 problem, we'll likely have colonized many other planets and moons. Likewise, by the year 17,014,118,346,046,923,173,168,730,371,588,410 we might have gone through several universes. The thing is, we often include things in Wikipedia that seem irrelevant. That's because an encyclopedia is supposed to contain certain facts and pictures, no matter how irrelevant they may seem. The year 10,000 problem for example, seems irrelevant to many people, but we still include it in Wikipedia. Voortle 02:13, 1 August 2006 (UTC)
replies: text:  I thought we had resolved this issue when you removed the text here.  Apparently we had not resolved the issue, because you added it back in a few hours ago.  "Individual scheduled ... future events should only be included if the event is notable" (from WP:NOT).  This event is very unnotable.  Can someone else please weigh in here, because I'm almost sure I'm not the only one that thinks this text does not belong.  ~a (user • talk • contribs) 16:49, 3 August 2006 (UTC)

text:  I also refer back to the origins of this page:  "It should be immediately obvious why the year 298237492374 issue is not a pressing issue."  The year 17,014,118,346,046,923,173,168,730,371,588,410 does not belong.  Right?  ~a (user • talk • contribs) 17:00, 3 August 2006 (UTC)

text: (weighs in) The 64-bit solution is widely proposed, so mentioning its wrap date is appropriate. Adding the 128-bit date is totally speculative, and, absent a cite, original research. Generally humor is disapproved of in Wikipedia. I think the mild "not considered a problem" could be a reasonable exception, but the vast amount of edit churning it seems to generate may prove otherwise. --agr 17:32, 3 August 2006 (UTC)

text: It's not original research to mention the 128bit figure of RFC2550, it's the question whether adding it makes the article better. Is it a relevant solution? No; counting seconds using a 128bit counter is technically inferior. Does it help illustrate why large counters postpone the wraparound indefinately into the future? I don't think so either. I'd guess that this is the consensus of the editors on this article. Perhaps agr is right that this article should really explain why the 292,471,208,678 problem it is not a pressing issue. Sadly. — squell 21:41, 3 August 2006 (UTC)
thread_title:  Extending the problem beyond the year 292,471,208,678