Difference between revisions of "Talk:1340: Unique Date"

Explain xkcd: It's 'cause you're dumb.
Jump to: navigation, search
Line 42: Line 42:
 
The problem of the date rolling back is partially mitigated by storing the year as an integer instead of as characters, such as how certain Spreadsheet programs, such as OpenOffice Calc, stores years as a 16-bit signed integer. This doesn't solve the issue, only pushing it back to be the year 32768 problem. This is even less of an issue for 64 bit Unix time, which expire on 15:30:08 UTC on Sun, 4 December 292,277,026,596. It's also important to note that the dates, such as 99, or 00 should not be seen as digits, they should be seen as characters (unless, of course, they are BCD digits, which entirely defeats the purpose of shortening the date to 2 characters length). This might seem trivial, but I think it's an important difference.[[Special:Contributions/108.162.216.41|108.162.216.41]] 02:46, 11 March 2014 (UTC)
 
The problem of the date rolling back is partially mitigated by storing the year as an integer instead of as characters, such as how certain Spreadsheet programs, such as OpenOffice Calc, stores years as a 16-bit signed integer. This doesn't solve the issue, only pushing it back to be the year 32768 problem. This is even less of an issue for 64 bit Unix time, which expire on 15:30:08 UTC on Sun, 4 December 292,277,026,596. It's also important to note that the dates, such as 99, or 00 should not be seen as digits, they should be seen as characters (unless, of course, they are BCD digits, which entirely defeats the purpose of shortening the date to 2 characters length). This might seem trivial, but I think it's an important difference.[[Special:Contributions/108.162.216.41|108.162.216.41]] 02:46, 11 March 2014 (UTC)
 
: 3rd of October won't happen for another seven months. {{unsigned ip|173.245.53.125}}
 
: 3rd of October won't happen for another seven months. {{unsigned ip|173.245.53.125}}
 +
:: As a (culturally) dd/mm/[yy]yy person (and ignoring, for brevity, the different options for delimiter), I find yyyy-dd-mm as illogical as mm/dd/yyyy... Why should anybody switch 'precision direction', mid-way?  Still, as someone who went through the Y2K process ''and'' worked with colleagues across the Atlantic, I tend to use dd/Mmm/yyyy habitually in "for humans" systems (giving the abbreviated month spelling to avoid all ambiguity, as well as full year-number), or my own "yyyymmdd[-hhmm[ss[.ddd...]]]" format in (informal and internal) programming situations, with comments attached to any conversion routines (inwards and outwards).  ((And, yes, there ''are'' ISO/other standards, but I find converting from/to them and internally working with my own long-practiced format works best, for me.  YMMV.  But be aware of how'd you deal with (or ignore) Leap Seconds!)) [[Special:Contributions/141.101.98.47|141.101.98.47]] 14:58, 12 March 2014 (UTC)

Revision as of 14:58, 12 March 2014

My first thought was that he makes fun of people that consider dates like the 12.12.12 as important. As any other date they occur only once and are thus not more special. 108.162.254.66 04:37, 10 March 2014 (UTC)

Good point, I have added something about that. 108.162.246.117 04:49, 10 March 2014 (UTC)

Possibly related to the upcoming Pi Day. Also, next year's Pi Day will be 03-14-(20)15, which a few images going around on the Internet have made an annoyingly big deal about. 108.162.237.64 06:24, 10 March 2014 (UTC)

So - Maybe I suck at searching (I do), but I can't find any information about us being limited to 4 digits in our calendar system...?173.245.53.107 08:38, 10 March 2014 (UTC)

Most of the computer software that handles dates would have problems with more (or less) than four digits. Why bother with variable year length when you can just take the first four characters of "2014-03-10" and it works for the next 8 thousand years? 103.22.200.103 09:42, 10 March 2014 (UTC)
Also, most digital displays are limited to four digits for the year. 103.22.200.103 09:43, 10 March 2014 (UTC)
And I don't think we actually start address that sooner that in September 9999. It will be Y2K over again! .... not sure where will people of 9999 get Fortran and Cobol programmers, though. Maybe we should freeze some before we run out of them. :-) -- Hkmaly (talk) 10:20, 10 March 2014 (UTC)
Check this out.--Rael (talk) 21:38, 10 March 2014 (UTC)
I'm with you. I suppose there may be places where leading zeros are used (somewhere in software where memory space has been set aside, I suppose) but I can't think of any common system where one has to use five digits when using a four digit number.
When we get to December 31, 9999 (assuming he Gregorian calendar is still in use (BIG assumption)) the next day will simply be January 1, 10000 because, as you said, the Gregorian calendar isn't limited to four-digit years. And, as I say, anyone who think there is some problem with writing years as four digit numbers is simply demonstrating that they are not someone to take seriously. 199.27.128.84 16:32, 10 March 2014 (UTC)

After visiting the website for the "Long Now Foundation", I find I'm left wondering - why, oh why, would they stop at using a five digit year? why not six? eight? ten? sixteen? thirty-two? Brettpeirce (talk) 12:06, 10 March 2014 (UTC)

I think the point in the comic title is that writing years always with 5 digits is as significant as the zero to the left it will take to do so for most of the next 8000 years. FlavianusEP (talk) 12:25, 10 March 2014 (UTC)

My first thought was that the comic was about date formats and yyyy-mm-dd being better than yy-mm-dd or dd.mm.yy. 173.245.53.138 12:40, 10 March 2014 (UTC)

Dynamic?

Wanna bet that this comic always shows the current date?--Henke37 (talk) 10:23, 10 March 2014 (UTC)

Haha, that's a great observation! I wish it were so, I'll check again tomorrow. If it's not, someone email Mr. Munroe to make it so, great idea. -- Adityarajbhatt (talk) (please sign your comments with ~~~~)
It's 00:07 (11th of March) right now in China where I am currently located and it still shows 10th of March...just for the record 108.162.225.191 16:13, 10 March 2014 (UTC)

It's funny that Randall seems to have never heard of RFC 2550, which goes than the Long Now Foundation in expanding the representable date range. 173.245.53.161 15:05, 10 March 2014 (UTC)

Technically, there will be another 2014-03-10; on October 3rd. - 108.162.219.65 16:01, 10 March 2014 (UTC)
It would actually be 2014-10-03 "under our system" as stated in the comic. Technically. 108.162.237.64 17:14, 10 March 2014 (UTC)
It's like me saying that there will be another 2014-03-10 on March 14th. 173.245.50.63 19:45, 10 March 2014 (UTC)

I wonder if this is also somehow related to the Interesting number paradox. 199.27.128.29 18:48, 10 March 2014 (UTC)


The problem of the date rolling back is partially mitigated by storing the year as an integer instead of as characters, such as how certain Spreadsheet programs, such as OpenOffice Calc, stores years as a 16-bit signed integer. This doesn't solve the issue, only pushing it back to be the year 32768 problem. This is even less of an issue for 64 bit Unix time, which expire on 15:30:08 UTC on Sun, 4 December 292,277,026,596. It's also important to note that the dates, such as 99, or 00 should not be seen as digits, they should be seen as characters (unless, of course, they are BCD digits, which entirely defeats the purpose of shortening the date to 2 characters length). This might seem trivial, but I think it's an important difference.108.162.216.41 02:46, 11 March 2014 (UTC)

3rd of October won't happen for another seven months. 173.245.53.125 (talk) (please sign your comments with ~~~~)
As a (culturally) dd/mm/[yy]yy person (and ignoring, for brevity, the different options for delimiter), I find yyyy-dd-mm as illogical as mm/dd/yyyy... Why should anybody switch 'precision direction', mid-way? Still, as someone who went through the Y2K process and worked with colleagues across the Atlantic, I tend to use dd/Mmm/yyyy habitually in "for humans" systems (giving the abbreviated month spelling to avoid all ambiguity, as well as full year-number), or my own "yyyymmdd[-hhmm[ss[.ddd...]]]" format in (informal and internal) programming situations, with comments attached to any conversion routines (inwards and outwards). ((And, yes, there are ISO/other standards, but I find converting from/to them and internally working with my own long-practiced format works best, for me. YMMV. But be aware of how'd you deal with (or ignore) Leap Seconds!)) 141.101.98.47 14:58, 12 March 2014 (UTC)