2016 Bug Hits Text Messages, Payment Processing

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?"

Comments

My wireless landline phones all failed 1/1/2010

[Gorobei]

No dial tone, no incoming calls.

Had to reset the internal datetimes back to 2007, then they started working again. Nice job, Panasonic.

Re:10 hex is 16 decimal

[Posting=!Working]

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:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z

[Chabil Ha']

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:Some kind of...

[Mr Z]

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 again.

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).

In this case, one guy is talking BCD, another guy assumed binary, and it was no big deal until 2010 rolled around and 10 suddenly became 16.

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.