2016 Bug Hits Text Messages, Payment Processing 340
An anonymous reader writes "It seems some systems are suffering from a Y2K16 bug. When 2009 ticked over to 2010, some Australian EFTPOS machines skipped to the year 2016. Coincidentally, some Windows Mobile users are also having issues with their new year SMSes coming from 2016. What function could cause this kind of error?"
Why (Score:5, Funny)
Uncle Bill decided to do some coding. That's why.
Re: (Score:3, Interesting)
WHY DO PEOPLE INSIST UPON REPLACING THE FIRST ZERO (Score:2, Interesting)
It is 2016, not 2k16. Is there something cool about replacing a zero with a k now?
Any EE will tell you that 2k16 means 2.16k or 2160. How does this garbage continue making it to the front page?
Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z (Score:4, Interesting)
No to mention Y2K was a pun of sorts for shortening 2000 to three bytes from four. Now we're taking more space than the original; Y2K16 vs 2016. Those COBOL programmers would be rolling in their graves.
Re: (Score:3, Insightful)
Any EE will tell you that 2k16 means 2.16k or 2160. How does this garbage continue making it to the front page?
Actually, most EE's I know are smarter than that. The fact that X means Y in some contexts does not mean X means Y in all contexts. Most competent speakers of the language have no trouble determining meaning, taking context into account. It's rare that someone manages to get an EE while lacking the level of intelligence required to do that.
Some kind of... (Score:5, Insightful)
0x09 = 9 decimal when interpreted as either binary or BCD.
0x10 = 10 decimal when interpreted as BCD, as 16 when interpreted as binary.
Re: (Score:2)
Guess that makes the most sense. Although I have a hard time imagining how to do this ... but considering how complex the code probably is, and in what hurry that Y2K fix was probably done, it's the most likely scenario.
Re: (Score:3, Interesting)
Well, certainly BCD confusion caused a similar problem for RISC OS. Machines have been skipping to 2012. More here:
http://www.riscository.com/ [riscository.com]
Re:Some kind of... (Score:5, Informative)
I don't think you quite have the hang of binary (10 would be 2, not 3).
Re:Some kind of... (Score:4, Funny)
Re: (Score:3, Funny)
You know, only yesterday on slashdot did I read a comment that said (in all seriousness) that there "are 11 kinds of people in the world, those who understand binary and those who don't". Facepalm indeed!
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Insightful)
Er, the "11" was in unary!
Re: (Score:2)
You know, only yesterday on slashdot did I read a comment that said (in all seriousness) that there "are 11 kinds of people in the world, those who understand binary and those who don't". Facepalm indeed!
The quote I like is:
There are 3 kinds of people in the world; those that can count and those that can't.
Re: (Score:2)
I seem to remember it being somewhat to the effect of “there are 11 types of people in the world... people who think binary is the base system everyone should be using, and people who don’t”.
The implication is that the person saying that thinks that unary (base-1) should be used, which is a degenerate “tally” counting system where every place value is equal to 1^n. (Degenerate because 1^n = 1^(n+1), which destroys the whole notion of place value in unary.)
11 in unary = 1x1^1 +
Re: (Score:2)
I don't think you quite have the hang of binary (10 would be 2, not 3).
Mommy, what's binary???
Re: (Score:3, Interesting)
Re:Some kind of... (Score:5, Funny)
Re: (Score:2, Funny)
Give him a break. This whole thread is made of such epic fail that it could only be unforged in Mount Doom.
10 is 3 in binary indeed...
Re:Some kind of... (Score:5, Informative)
Let me see if I can straighten it out, then.
0x10 is a hexadecimal number, 0001 0000 binary, 16 decimal.
0x10 is a BCD number, 0001 0000 binary, 10 decimal.
(BCD is an encoding system, not a base system. In hex or binary it’s given in encoded form, but in decimal it’s given in decoded form.)
Re: (Score:3, Interesting)
Someone obviously reverse engineered it. They saw 0x02 in 2002 and 0x03 in 2003 and assumed it was an 8-bit binary number of years since 2000. They should have read the specs instead to learn it was BCD (a leftover relic from the mainframe era that needed to die over a decade ago). OTOH, the spec designers should have use plain unsigned binary (which would have lasted until 2255 instead of 2099). Or better yet, don't even break up dates into bytes and nybbles; leave them encoded as number of nanoseconds
Re: (Score:2)
WTF indeed... who were you replying to?
Re: (Score:2)
Re:Some kind of... (Score:5, Informative)
> (a leftover relic from the mainframe era that needed to die over a decade ago)
No no no. Binary coded decimal is necessary and useful. When you divide 1 by 10, you should get 0.1, not 0.10000000000000001 (which is what you get if you for instance open up a python interpreter and ask for 1.0 / 10.0).
Monetary amounts, and currency conversion rates are examples of something you should never, ever use standard binary floats for.
Fact: Many major databases use some form of BCD for representing currency values. Enough so that IBM added a dedicated decimal FPU for their power6 series - it's so common on business database servers that it actually saves a lot.
Re: (Score:3, Informative)
> (a leftover relic from the mainframe era that needed to die over a decade ago)
No no no. Binary coded decimal is necessary and useful. When you divide 1 by 10, you should get 0.1, not 0.10000000000000001 (which is what you get if you for instance open up a python interpreter and ask for 1.0 / 10.0).
Monetary amounts, and currency conversion rates are examples of something you should never, ever use standard binary floats for.
Fact: Many major databases use some form of BCD for representing currency values. Enough so that IBM added a dedicated decimal FPU for their power6 series - it's so common on business database servers that it actually saves a lot.
Here's [sun.com] a useful document from Sun on the matter (warning: pdf). The title is absolutely spot on: "What Every Computer Scientist Should Know About Floating-Point Arithmetic"
Re: (Score:2)
Excel stores its date/time as floats. The fractional component is for time of day, and the whole number is for the number of days since the relevant epoch, either 1st January 1900 or 4th January 1904 depending on the platform used.
Re: (Score:2)
It displays them as decimals, Do you have any reason to believe that the actual storage is floating point rather than fixed point decimal?
Re: (Score:2)
Yes. I read the fine manual, which says:
Date Data Type
Date variables are stored as IEEE 64-bit (8-byte) floating-point numbers that represent dates ranging from 1 January 100 to 31 December 9999 and times from 0:00:00 to 23:59:59. Any recognizable literal date values can be assigned to Date variables. Date literals must be enclosed within number signs (#), for example, #January 1, 1993# or #1 Jan 93#.
Date variables display dates according to the short date format recognized by your computer. Times display
Re: (Score:2)
The new year always starts with floats.
Re:Some kind of... (Score:4, Insightful)
0x10 is 16 in hexadecimal, not binary
0x10 is still 16 in binary.
(0x10 always means 0001 0000 in binary. The question is whether that number is interpreted in BCD, i.e. 10, or as a binary integer, i.e. 16.)
Re: (Score:2)
10 hexadecimal is 16 decimal is 10000 binary.
The phrase "0x10 is still 16 in binary" could be interpreted two ways that make absolutely no sense. Consider these two sentences as models: "Rojo means 'red' in Spanish," and "Red is 'rojo' in Spanish." In both cases, "in Spanish" indicates to the reader that "rojo" is a Spanish word. No number in the sentence "0x10 is still 16 in binary" is in binary. 0x10 is a hexadecimal number, and 16 is a decimal number. Your sentence can't be interpreted in either w
Re: (Score:2)
“Binary” refers to its internal number representation (encoding system), not its base system.
You have two types of integer in computing: binary and BCD. The base system it’s written in is independent of the encoding system used.
Re: (Score:2)
Hmmm....
(Note: In the blockquote above, I used "^" to indicate superscript,
Re: (Score:2)
Re:Some kind of... (Score:4, Informative)
0x10 means 0001 0000.
0001 0000, if that's a binary number, means decimal 16
0001 0000, if that's binary coded decimal (BCD), i.e. decimal 0-9 represented as 0000 to 1001, means decimal 10.
(If 0001 0000 was little endian (with 4-bit groupings) it would mean binary 1)
1234 in binary (4D2 in hexadecimal) is 0000 0100 1110 0010
1234 in BCD is 0001 0010 0011 0100
Re: (Score:2)
traditionally appending a 0x denotes that the value is in hexadecimal
Yes, which is why it is 16 (decimal) in binary. It’s 16 (decimal) in ANY base number system, because you have to convert it out of hex, and done so properly it will always still be 16 in decimal.
You’re confusing the number’s base system (10 hexadecimal, 0001 0000 binary, 16 decimal) with its encoding system (0x10 / 0001 0000 / 16 binary, or 0x10 / 0001 0000 / 10 BCD).
Re: (Score:2)
Well then it would just be 100x as AWESOME!!!!
coffeecoffeecoffee...
Re: (Score:2)
You’re confusing its base with its encoding. Binary is both a base system and an encoding system. If I was talking about the binary base system, then yes, 0x10 is always 0001 0000 in the binary base system. I was talking about the encoding system.
0x10 can be either binary encoded (bits representing powers of 2) or it can be BCD (nibbles representing powers of 10).
0x10 is 16 in the binary encoding system:
0x10 = 0001 0000 = 16.
All three representations are binary encoded.
0x10 is 10 in BCD:
0x10 = 0001 00
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
Some more observations:
Before you argue that 00010000 is somehow different from 0001 0000, the space is just there for readability. If you pop open a memory viewer and look at a hex dump of RAM, you'll see that 10 decimal stored in BCD in a byte of RAM lo
Re: (Score:3, Interesting)
Just nit-picking here, but the decimal number 10 and the BCD number 0001 0000 would be incorrectly written in hexadecimal as 0x10. The correct conversion, had the programmer kept better track of the formatting he was using is 0x0A. It would have been avoided with a practice like converting everything to binary before converting to hex, even if you think it's already binary. Really though he probably just needed better comments in the code.
It's basically just a result of not keeping track of your units -
Re:Some kind of... (Score:5, Interesting)
I wouldn't say it's incorrect. It's quite common to represent binary strings as hexadecimal strings regardless of the underlying format. After all, what units would you apply to an x86 opcode? what about a portion of an H.264 bit stream? Or heck, even a floating point number? 0x3F800000 is the hexadecimal representation of the IEEE 754 single precision floating point number 1.0. (And if you don't think people write floating point numbers in hex, think [gnu.org] again. [qc.edu]
Now the integer 10 encoded in standard binary format would be 1010, which written in hexadecimal would be A (or 0x0A in C syntax). It also happens to be the same as if you directly went from base 10 to base 16 and ended up with 0x0A. If the decimal number were encoded as BCD, though, the resulting binary string would be written 00010000 (or 0001 0000 if you so choose--the spaces are insignificant!), and that binary string is equivalent to the hexadecimal string 0x10. Note that "hexadecimal string" does not imply base-16 number. It's just a shorter representation than the binary string. It is not equivalent to the hexadecimal number 0x10. When I said "written in hexadecimal", I meant "when written as a hexadecimal string."
Look at it this way: If I were trying to hex-dump a file full of BCD values and the file had nothing but the value "10" (decimal) over and over in each byte, I would see 0x10 in every byte, not 0x0A. Try it. Go write a 6502 or x86 program that uses that processor's BCD mode, and then do a hex dump of memory. Or better yet, go get a BCD number, and pass it to the "%x" format specifier in your favorite C compiler (or other language that uses C's format specifiers).
I think you mean to say "one guy is talking BCD, another guy assumed standard binary integer. The "B" in BCD is "Binary" after all... Every number stored in the computer is in one binary format or another. Saying "assumed binary" is roughly the same as "assumed the number was stored in a computer." You have to say which format.
Re: (Score:2)
Re:Some kind of... (Score:5, Informative)
I used 0x10 because that's standard ANSI C (and ECMA-334 C#), and C is what seems to be spoken on
Just shows... (Score:2)
Kids, when you've written code to drive 40-character HP 7 by 5 LED displays, with the data and the buffers having to fit into 256 bytes of memory, then you can argue with msuave.
Re: (Score:3, Funny)
I don't think I have a lawn any more.
Re: (Score:2)
There are only 10 kinds of people in this world, those who understand binary, and....
4-bit years? (Score:2, Insightful)
A 4-bit year field? Wrapping from 9 to 0 (16) ?
Microsoft (Score:5, Informative)
Seems Microsoft is supplying some code [microsoft.com] for EFTPOS machines that is common with Windows Mobile, so it's most likely the same bug in both.
Re: (Score:2)
Re:Microsoft (Score:4, Informative)
Yes they do [google.com] (almost in every atm actually).
My wireless landline phones all failed 1/1/2010 (Score:5, Interesting)
No dial tone, no incoming calls.
Had to reset the internal datetimes back to 2007, then they started working again. Nice job, Panasonic.
Text messaging from the future (Score:4, Funny)
and they can bill you the future rate as well (Score:3, Funny)
and they can bill you the future rate as well. In the Year 2016 texts are $2 each way. and your bill in 6 years past due.
Re: (Score:2)
Imagine that we now have to suffer a lame Sci-Fi show based on the lame premise that the hero/ine send sms from the future to.....
Text Messages from the FUTURE!! BRILLIANT!! It's just like phone calls, ham radio signals, and that movie about dreams from the future! All of those grossed huge sums!!! I have no idea what all the rest you where trying to get at but expect to see this movie in 2012!
Your Friends,
New Line Cinema
10 hex is 16 decimal (Score:5, Informative)
Could be botched string parsing. Could be binary coded decimals interpreted as binary numbers: BCD encodes two decimal digits in the high and low nibbles of a byte. Therefore BCD 10 is 0001 0000 in binary, which is 16 in decimal.
Re:10 hex is 16 decimal (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Two digits is fine, now ... until we approach 2100. I plan to be retired by then, so I don't care. Fear those who are using ONE digit (that has happened). But in this case I can believe that someone used the wrong conversion like maybe: strtol(year_str,NULL,0x10).
Re: (Score:2)
Apparently not.
why even ONE digit? (Score:2)
These messages had better not be spending years getting routed around the phone company network. The phone can infer what year it is.
You don't need a month even. I'm not sure you need a day, and you could probably skip the rest as well. This is a stupid waste of bytes, and thus air-time. It eats away at space that could go to the message or anything else useful.
Suppose we really do want sender-side time. OK, let's use an 8-bit count of minutes. That covers over 4 hours. We take UNIX time (UTC seconds since
Re: (Score:2)
Re: (Score:2)
Two digits is fine, now ... until we approach 2100.
Wrong. It's only fine until we approach 2010. "Microsoft... nothing is impossible!"
Re: (Score:2)
I thought the whole Y2K fiasco taught people not to use two digits to represent years.
Correct. However, you’re ignoring a significant piece of data that can be used to reconstruct the full year from only the last two digits.
Context.
Your cellphone already knows the current full year, and nobody will keep records of SMS messages for 100 years (and if they did, it would be in a summary form that showed the full year of its creation).
In other words, use the first two digits of the current year (which you know), and if that creates a date in the future, subtract 100. The only time this meth
Re:10 hex is 16 decimal (Score:5, Informative)
The specification for the SMS message format pre-dates Y2K by about 15 years. I came across it in 1995 (and thought it was useless - what sort of idiot would try to fit a message into 160 characters? And who would want to type it on a 12-button keyboard?). Where I worked, nobody worried about Y2K until about 1998.
Re:10 hex is 16 decimal (Score:4, Funny)
> what sort of idiot would try to fit a message into 160 characters?
If we find the answer, twitter will finally make sense.
Re: (Score:3, Funny)
somany ppl mock the bran-dead twits just for having n0thing 'mportant to say, fu
elishly beleafing that 160 char messagesis senless. In fact, the explanation is
Re:10 hex is 16 decimal (Score:4, Interesting)
Can someone tell me what the advantage of swapped nibble encoding are? Other than just being annoying as fuck when you're trying to decode it?
For those too lazy to read the link , swapped nibble encoding is
"BCD code where nibbles within octet is swapped. E.g.: 0x31 Represents value of 13"
So for the format YY MM DD HH MM SS TZ (Time zone in 15 minute increments from GMT) instead of 10 01 03 10 11 43 24 for 2010 Jan 3 10:11:43 time zone 24 (GMT +6) you get the identical data but in the less readable form of 01 10 30 10 11 34 42 (and now it can be confused for 2001 Oct 30 10:11:34 AM. Bonus!)
It's just complete idiocy to me. Is there some reason you'd want the date/time stamp slightly harder to read?
Re: (Score:2, Insightful)
That may be an attempt to distinguish the BCD values from normal binary numbers. The only value for which swapped nibble encoding equals binary encoding is 0, so a test-case would catch a misinterpretation easily. I've seen a unit test which tests the algorithms with 2005 for the year. That test will not catch an error in a single-byte-year algorithm which mistakes non-swapped BCD for binary or vice versa.
Re: (Score:3, Informative)
It makes a lot more sense in little endian.
Re:10 hex is 16 decimal (Score:4, Informative)
The endianness may make it more sensible. If you have 0x12345678 represented using the correct endianess (the Intel one, not the Sun one), it'll be stored as 0x78563412. Using reverse nibble notation, it'll be 0x87654321.
But as far as I remember, it is caused by oldold ties to the 4004, which was a 4-bit CPU, inherited via the 8008 and 8080 by the 8086 and 8088.
Re: (Score:2)
They're doing YEAR = BCDYEAR + 2000... hooray for clueless programmers!
What makes it stupider is that with SMS they have to swap the nibbles first... and decode the other fields as BCD too.
And this is clearly a client-only bug, so dozens of codebases will have to be fixed and millions of devices updated. The typical lifetime of a cellphone means that the broken ones may simply get trashed rather than go through the trouble of an update.
Re: (Score:3, Interesting)
What? I looked at someone else's link showing the SMS data format, and it is quite clear and consistent. Dates are six nibbles of BCD, with the low nibble coming first in both the date and phone number. The year is in exactly the same format as the month and day: two BCD digits. It's not their fault that so many programmers were morons and couldn't comprehend to process the year (before adding the century) in exactly the same way as the month and day.
As for "lessons learned from Y2K", this is not a situati
Y2K16-Bug? (Score:2)
It's a Y2K10-Bug. The Y2K-Bug was not titled Y1900-Bug (to name one of the bug types) as well.
Re: (Score:2)
Y2K10 would be 200010. Silly contractions...
Re: (Score:2)
Y2K10 would be 200010. Silly contractions...
Then again, in electronics 2K10 would be parsed as 2.10 thousand, or 2100.
Re: (Score:2)
So... Y2K+10 would be more correct?
Sure. But 2010 is shorter anyway (same for Y2K10), so why? Just write 2010...
Re: (Score:2)
I was actually considering that something like this might happen, due to the Y2K craze. People are scrambling to "fix" that hyped problem, testing being done haphazardly and only to make sure that it works "for now" because we have "more time later".
Then later, nobody cared about it anymore and nobody cared about the next decade. I'm actually quite happy that the biggest problem seems to be that text messages come from the future. Hey, I didn't care about those coming from the past either, so I'm fine with
Official explanation (Score:5, Funny)
It's to avoid the world ending in 2012 by skipping straight to 2016. We've left a few years either side of the fateful date as a safety buffer.
Its the LHC! (Score:2, Funny)
Re: (Score:2)
Huh, I always thought the LHC would cause a resonance cascade.
Re: (Score:2)
Yes, but a temporal resonance cascade. It can send people forward to 2016, or backwards to 1620, depending on your cell phone's software.
Function? (Score:2)
* points finger at Duct Tape Programmers (Score:5, Funny)
Time to quote Joel (from www.joelonsoftware.com):
Jamie Zawinski is what I would call a duct-tape programmer. And I say that with a great deal of respect. He is the kind of programmer who is hard at work building the future, and making useful things so that people can do stuff. He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40. And he will wield them elegantly even as your go-cart is careening down the hill at a mile a minute. This will happen while other programmers are still at the starting line arguing over whether to use titanium or some kind of space-age composite material that Boeing is using in the 787 Dreamliner.
When you are done, you might have a messy go-cart, but it’ll sure as hell fly.
Hey, Jamie! Your proprietary date datatype didn't fly! Would you please turn around and fix it?
Re:* points finger at Duct Tape Programmers (Score:4, Insightful)
Yes, but that's just the point isn't it ?
There are 10 types of people ...
1. Those who will make a solution that will work for perhaps 30 or 35 years, because it is "good enough" for the foreseeable future, ala Y2K, 2032 for linux etc ...
2. Those who will want to do unit tests to see if the date function still works in the year 9500, and won't pass it through QA until it does.
Now, consider the PHB, when you tell him that solution 1 will be up and running in 5 minutes, whereas solution 2 will be up and running in about 5 years, once the specification has been formalized and ratified by the UN security council.
Which solution will the PHB choose I wonder ? Programming has always been a compromise, no one *really* expects that something they code today will still be around in 35 or 40 years, it's only occasionally that something *does* survive that long (COBOL legacy systems etc), and come and bite us in the ass when the new millenia arrives.
Having said that, I wonder how many of the "buzzword" languages we see today will still be around in the next 40 years ? The concept of longevity might have been relevant in the 60's, these days it's more a case of a complete rewrite every year or so.
Re: (Score:2)
Dude, it's 2038 for 32 bit Unix/linux, not 2032. 64 bit is good until some time after the Sun's end of life.
The guys who designed in the 2038 limit not long after 1970 made a solution that would last 68 years. I call that pretty good. Long enough to be damn sure to be retired or dead before trouble hits.
Re: (Score:2)
In Jamie's defense, I've read that book, and Joel's interpretation of what he said is completely, totally, 100% off-base. Plus the name "duct-tape programmer" is offensive. Usually, I'm a fan of Joel. But then again, usually he's not so wrong and offensive in his articles.
(The sad thing is that I agree with the general principle of the article, but the way it's presented, and the way it's attributed to Jamie, is completely off-base.)
Re: (Score:2)
I personally think Joel is one damn smart fellow. After reading his biography, I am also pretty sure he is a very dependable and likeable human being.
The original comment was indeed a joke. I do think duct tape programming has its uses, despite what I earlier argumented for (the topic was slashdotted some time ago), and I do think Jamie by now is probably earning his PhD. It is just that I do also think the type of error the 2016 bug is can indeed be attributed to the "duct tape programming" attitude. I've
Re: (Score:3, Informative)
It is just that I do also think the type of error the 2016 bug is can indeed be attributed to the "duct tape programming" attitude.
But that's exactly what Jamie *isn't* talking about. He never said anything about not designing the system, or doing the design ad-hoc, all he's saying is two things:
1) If your code is too complex, uses too many obscure language features, or has a structure that can't easily fit in the average person's head, it's likely to be more buggy since some of your team will never fully u
You could mess with people! (Score:4, Funny)
Re: (Score:2)
You sir, are an evil, evil person. Also, your ideas are intriguing to me and I wish to subscribe to your newsletter.
Re: (Score:2)
who would have predicted that the Mayan calendar was really right? Glad I loaded up on all the MSFT back in '10.
Although I agree that MSFT performing well would be quite a (figurative) catastrophe, but in case of a real catastrophe, what good does it do to load up on any kind of stock certificate?
And yes, stock certificates are generally printed on paper that's far too stiff and not absorbant enough for the "obvious" purpose...
MESSAGE FROM THE FUTURE (Score:3, Insightful)
This is an indication that the human race will survive 2012! Rejoice!
no that's a Y210 bug (Score:4, Informative)
Y bugs are named for the year in which they occur, not the year they jump....otherwise Y2K would have been Y1.9K, or even better YMCM
Re: (Score:2, Insightful)
Mod points, I wish I had them.
Re:Future SMS (Score:5, Funny)
I did but all they told me was that I talk like a fag and my shit's all retarded.
Re:Future SMS (Score:5, Funny)
Should have fed them a politician. Al Gore comes to mind.
Msge to fleet command: Avoid the 3rd rock, the inhabitants taste like shit!
Re: (Score:2)
The future replied back saying that climate change was a hoax and that Al Gore is now broke holding worthless carbon credits.
The second message said Apophis took care of any warming and humans where being so smart by pre-emotively dumping trillions of tons of CO2 into the atmosphere.