Slashdot Mirror


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

340 comments

  1. Why by Anonymous Coward · · Score: 5, Funny

    Uncle Bill decided to do some coding. That's why.

    1. Re:Why by TheLink · · Score: 2, Interesting

      Nah, it's more likely the same bunch that did excel 2007... Anyone remember the infamous 77.1 * 850 = 100000 Excel 2007 bug? :)

      --
    2. Re:Why by yossarianuk · · Score: 1

      thankfully I migrated (upgraded) all my machines to Linux and Openoffice in 2005 so thankfully I did not experience that bug.

    3. Re:Why by sciencewhiz · · Score: 1

      "Uncle Bill" was actually a very good coder. From http://www.thocp.net/companies/microsoft/microsoft_company.htm

      Using the Altair's published specifications, Gates and Allen created a simulator on a DEC PDP-10 computer that allowed it to emulate the MITS machine. Working day and night, they created the first version of MICROSOFT BASIC for the Altair

      Jan 2, Bill Gates and Paul Allen complete BASIC

      Allen is going to deliver it to MITS president Ed Roberts in Albuquerque. Realizing he didn't have a way to load it into the computer, Paul Allen hand assembled a loader program for BASIC at 30,000 feet in the air, on the flight to New Mexico. Even though it had never been tested on an actual machine, it ran perfectly on the very first try.

      If only the rest of Microsoft's Software Engineers were as good as Bill Gates and Paul Allen.

  2. Some kind of... by msauve · · Score: 5, Insightful

    BCD/binary mismatch?

    0x09 = 9 decimal when interpreted as either binary or BCD.

    0x10 = 10 decimal when interpreted as BCD, as 16 when interpreted as binary.

    --
    "National Security is the chief cause of national insecurity." - Celine's First Law
    1. Re:Some kind of... by GrumpySteen · · Score: 1, Informative

      I think you mean hexadecimal. When 10 is interpreted as binary, it's 3 not 16.

    2. Re:Some kind of... by Anonymous Coward · · Score: 5, Informative

      I don't think you quite have the hang of binary (10 would be 2, not 3).

    3. Re:Some kind of... by Anonymous Coward · · Score: 0

      Yes, this seems likely, doesn't it? And it means the idiots didn't learn the lesson of Y2K: a year is a 2-byte value (yeah, yeah, the odds of that code being around in 2100, let alone 2256, are really, really low; but still ...).

    4. Re:Some kind of... by Anonymous Coward · · Score: 1, Informative

      he meant binary coded decimal you clod

    5. Re:Some kind of... by kalidasa · · Score: 2, Interesting

      Do *you* often work with years as floats?

    6. Re:Some kind of... by Anonymous Coward · · Score: 0

      What "16 when interpreted as binary" means is that you take the bits and interpret them as a binary encoding of a number (as opposed to interpreting them as a BCD encoded number). Programmer parlance.

    7. Re:Some kind of... by kalidasa · · Score: 4, Funny

      Facepalm. I'm gonna get mauled for this one.

    8. Re:Some kind of... by Opportunist · · Score: 1

      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.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    9. Re:Some kind of... by ta+bu+shi+da+yu · · Score: 0

      0x10 is 16 in hexadecimal, not binary.
      10 in binary is 2, not 3.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    10. Re:Some kind of... by RichardJenkins · · Score: 2, Informative
      • The decimal number '10' would be encoded in BCD as '1010 0000'
      • '10' is not a valid BCD bitstring
      • When writing in base 2 (binary), '10' is the same number as '2' when writing in base 10
      • putting '0x' before a number indicates that it is written base 16 (hexadecimal)
      • '0x10' is 16 in decimal
    11. Re:Some kind of... by Anonymous Coward · · Score: 1, Insightful

      It's almost as if you're supposed to have some idea about what you're talking about before you publish.

      Still, at least people like you subsidize Twitter and blogger.com.

    12. Re:Some kind of... by betterunixthanunix · · Score: 1

      I wish I could mod this funny.

      --
      Palm trees and 8
    13. Re:Some kind of... by RichardJenkins · · Score: 1
      D'oh!
      • The decimal number '10' would be encoded in BCD as '0001 0000'
    14. Re:Some kind of... by msauve · · Score: 5, Informative

      No, I meant exactly what I said. I didn't say 0b01. 0x10 is the hexadecimal notation for "00010000" binary, which is 16 decimal.

      I used 0x10 because that's standard ANSI C (and ECMA-334 C#), and C is what seems to be spoken on /.. 0b00010000 is non-standard (but allowed by some compilers).

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    15. Re:Some kind of... by Anonymous Coward · · Score: 0

      Where's a "-1:Wrong" tag when you need it?

    16. Re:Some kind of... by oskard · · Score: 3, Funny

      Take it easy on him. After all, there are only 10 kinds of people in this world.

      --
      Sigs are for Terrorists.
    17. Re:Some kind of... by kesuki · · Score: 1

      agreed,
      "It is possible to perform addition in BCD by first adding in binary, and then converting to BCD afterwards. Conversion of the simple sum of two digits can be done by adding 6 (that is, 16 - 10) when the result has a value greater than 9. For example:
      1001 + 1000 = 10001 = 0001 0001
            9 + 8 = 17 = 1 1"

      if 17 in BCD is 10001.... he meant hexadecimal

    18. Re:Some kind of... by Anonymous Coward · · Score: 0

      • The decimal number '10' would be encoded in BCD as '1010 0000'
      • '10' is not a valid BCD bitstring
      • When writing in base 2 (binary), '10' is the same number as '2' when writing in base 10
      • putting '0x' before a number indicates that it is written base 16 (hexadecimal)
      • '0x10' is 16 in decimal

      The decimal number '10' would be encoded in BCD as "0001 0000', not '1010 0000'.
      '1010' is not a valid BCD bitstring.

    19. Re:Some kind of... by Anonymous Coward · · 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...

    20. Re:Some kind of... by ta+bu+shi+da+yu · · Score: 2, 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!

      --
      XML is like violence. If it doesn't solve the problem, use more.
    21. Re:Some kind of... by clone53421 · · Score: 3, 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.)

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    22. Re:Some kind of... by ae1294 · · Score: 1

      I don't think you quite have the hang of binary (10 would be 2, not 3).

      Mommy, what's binary???

    23. Re:Some kind of... by jonbryce · · Score: 1

      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.

    24. Re:Some kind of... by Anonymous Coward · · Score: 1, Funny

      The third (11 in binary, or III in Roman Numerals, 3 in standard numeric) kind of person is he who thinks he understands binary, but really doesn't.

    25. Re:Some kind of... by pipatron · · Score: 1

      You know, that quote is sort of correct if the person who said it belongs to the last group of people.

      --
      c++; /* this makes c bigger but returns the old value */
    26. Re:Some kind of... by ta+bu+shi+da+yu · · Score: 0, Redundant

      Uh? No, traditionally appending a 0x denotes that the value is in hexadecimal. Ask any C programmer.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    27. Re:Some kind of... by clone53421 · · Score: 4, 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.)

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    28. Re:Some kind of... by Anonymous Coward · · Score: 1

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

      No. clon53421... 0x10 is 10000 in binary which is 16 in DECIMAL
      the "0x" part means hexadecimal. You cannot have "16 in binary" because binary only has ones and zeros.

    29. Re:Some kind of... by Anonymous Coward · · Score: 0

      0x10 is '16' in binary. It's '16' in dec. It's '16' in any number system you want... the op is talking about the value 16 not a particular representation of it.

    30. Re:Some kind of... by xaxa · · Score: 3, 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

    31. Re:Some kind of... by Anonymous Coward · · Score: 0

      Except c programmers prepend the 0x; I know of no language in which it is appended.

    32. Re:Some kind of... by Mikkeles · · Score: 2, Insightful

      Er, the "11" was in unary!

      --
      Great minds think alike; fools seldom differ.
    33. Re:Some kind of... by Mr+Z · · Score: 1

      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 way--as saying "0x10 is ... in binary" or "16 [is] in binary"--and be anywhere near correct.

      At any rate, I agree with many of the other Slashdotters that there seems to be a BCD vs. normal integer disagreement issue in the software here.

    34. Re:Some kind of... by clone53421 · · Score: 1

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

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    35. Re:Some kind of... by kybred · · Score: 1

      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.

    36. Re:Some kind of... by mrslacker · · Score: 2, Interesting

      Well, certainly BCD confusion caused a similar problem for RISC OS. Machines have been skipping to 2012. More here:

      http://www.riscository.com/

    37. Re:Some kind of... by Anonymous Coward · · Score: 0

      Why on earth was this modded 'Insightful'? Funny maybe, but insightful? The standards are really slipping around here.

    38. Re:Some kind of... by calzakk · · Score: 1

      appending a 0x

      would give 100x. You mean 'prepending'.

    39. Re:Some kind of... by clone53421 · · Score: 1

      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 0000 = 10.
      All three representations are BCD.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    40. Re:Some kind of... by Mr+Z · · Score: 1

      Some more observations:

      • The decimal number 10 would be encoded in BCD as 0001 0000, which would be written in hexadecimal as 0x10
      • The decimal number 16 would be encoded in standard 2s complement integer format in binary as 0001 0000, which would be written in hexadecimal as 0x10

      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 looks like 16 decimal stored in standard integer representation in a byte of RAM, which is more than likely strongly related to the source of the "2016 error."

      (Note that I say "standard 2s complement integer format" to distinguish from other possible representations, such as floating point, etc.)

    41. Re:Some kind of... by clone53421 · · Score: 1

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

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    42. Re:Some kind of... by zippthorne · · Score: 1

      It displays them as decimals, Do you have any reason to believe that the actual storage is floating point rather than fixed point decimal?

      --
      Can you be Even More Awesome?!
    43. Re:Some kind of... by clone53421 · · Score: 1

      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 + 1x1^0 = 1 + 1 = 2
      11 in binary = 1x2^1 + 1x2^0 = 2 + 1 = 3

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    44. Re:Some kind of... by Mr+Z · · Score: 1

      “Binary” refers to its internal number representation (encoding system), not its base system.

      Hmmm....

      2. Mathematics. a. of or pertaining to a system of numerical notation to the base 2, in which each place of a number, expressed as 0 or 1, corresponds to a power of 2. The decimal number 58 appears as 111010 in binary notation, since 58 = 1 × 2^5 + 1 × 2^4 + 1 × 2^3 + 0 × 2^2 + 1 × 2^1 + 0 × 2^0.

      (Note: In the blockquote above, I used "^" to indicate superscript, since Slashdot eats <SUP> tags last time I checked.)

      And there are many, many numeric representations of integers in binary coding beyond standard 2s complement integer and BCD. Exp-Golomb, Redundant Binary, Densely Packed Decimal to name just a few.

    45. Re:Some kind of... by Mr+Z · · Score: 1

      Ooops, I meant to include this link to the dictionary entry.

    46. Re:Some kind of... by Anonymous Coward · · Score: 0

      Are you any relation to Leroy?:)

    47. Re:Some kind of... by Anonymous Coward · · Score: 1, Informative

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

      Let's try this again.

      In binary...

      Binary 00 = Decimal 0
      Binary 01 = Decimal 1
      Binary 10 = Decimal 2
      Binary 11 = Decimal 3

      BCD is something different. But you said binary. And by the way, I'm not aware of any BCD format in which 10 = 3.

    48. Re:Some kind of... by karnal · · Score: 1

      Well then it would just be 100x as AWESOME!!!!

      coffeecoffeecoffee...

      --
      Karnal
    49. Re:Some kind of... by ari_j · · Score: 1

      Or wants to make a self-deprecating joke about belonging to the last group of people. Similar to "There are three kinds of people in the world: Those who can count, and those who can't."

    50. Re:Some kind of... by Will.Woodhull · · Score: 1

      There are only 10 kinds of people in this world, those who understand binary, and....

      --
      Will
    51. Re:Some kind of... by Concerned+Onlooker · · Score: 1

      The new year always starts with floats.

      --
      http://www.rootstrikers.org/
    52. Re:Some kind of... by Anonymous Coward · · Score: 0

      While we're on the subject of weird (but not useless) number formats: 10 is 3 in Gray code.

    53. Re:Some kind of... by GrumpySteen · · Score: 1

      Whoops. It is 2. My bad for posting before the morning's caffeine kicked in, but at least I'm not as bad off as the people claiming that binary 10 = decimal 16.

    54. Re:Some kind of... by jonbryce · · Score: 1

      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 according to the time format (either 12-hour or 24-hour) recognized by your computer.

      When other numeric types are converted to Date, values to the left of the decimal represent date information while values to the right of the decimal represent time. Midnight is 0 and midday is 0.5. Negative whole numbers represent dates before 30 December 1899.

    55. Re:Some kind of... by Skapare · · Score: 1

      0x10 is 8 bits with the pattern value of 00010000. That's 16 when interpreted as binary. The BCD (binary coded decimal) puts DECIMAL values in each 4 bit nybble. So 10 is 00010000 and 99 is 10011001. The problem seems to be that the year is encoded as the last 2 digits in BCD, so it is encoding 2009 as 00001001 and 2010 as 00010000 and 2011 as 00010001. Interpreting this (incorrectly) as binary gives 9, 16, and 17 (adding 2000 ... or formatting as 2 digits and prepending "20" ... gives 2009, 2016, 2017).

      Dumb programmers. Don't they have any real world experience?

      Dumb formatting. Obviously a legacy thing from the mainframe era.

      A 60 year old programmer would have known better.

      --
      now we need to go OSS in diesel cars
    56. Re:Some kind of... by ezzzD55J · · Score: 1

      unary would use only zeroes :)

    57. Re:Some kind of... by Anonymous Coward · · Score: 0

      Those who understand ternary, those who don't and those who confuse it with binary!

    58. Re:Some kind of... by Jane+Q.+Public · · Score: 1

      No, it can't, and no they aren't.

      0x10 is nothing in BCD, because the prefix "0x" is specifically stating that the following number IS hexadecimal. Several people have made that point already, but you don't seem to have gotten it.

    59. Re:Some kind of... by Skapare · · Score: 2, 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 since the epoch, times some scaling factor to fit less resolution in fewer bits as needed.

      --
      now we need to go OSS in diesel cars
    60. Re:Some kind of... by Jane+Q.+Public · · Score: 1

      Balderdash. You have made 2 different errors here.

      First, 0x10 is meaningless as BCD because the "0x" prefix designates this number as hexadecimal. What you stated is like saying $10 = £10, which just isn't so.

      Second, that space is NOT "just there for readability"! BCD encodes a decimal number (up to 9 maximum) in 4 binary digits, while hexadecimal can represent up to 15 in 4 binary digits. So the "binary" you see on the screen in a memory dump most definitely looks different when it represents BCD rather than Hexadecimal.

    61. Re:Some kind of... by Anonymous Coward · · Score: 0

      Indeed. Those who understand binary, those who don't, and GrumpySteen! :)

    62. Re:Some kind of... by barv · · Score: 1

      bcd/hex mismatch

    63. Re:Some kind of... by Bigjeff5 · · Score: 2, 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 - it's the same kind of error that destroyed a mars probe a few years back. One guy was talking inches, another guy centimeters, and nobody bothered to write down which units the numbers were for. Calculations for the landing were of by hundreds of yards and the probe smacked into the surface of the planet instead of floating down gently.

      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.

      --
      Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
    64. Re:Some kind of... by Mr+Z · · Score: 1

      Bullshit. I agree that the 0x prefix specifies that the digits that follow it are in hexadecimal. It does NOT specify the encoding of the data in the bits. For example, the hexadecimal string 0x3F800000 is the single precision IEEE floating point value '1.0', rendered as a hexadecimal string. Try it out and see.

      Binary coded decimal is just that: A binary coding scheme for decimal values. How you render the binary string for human readability purposes is up to you! That's just the same as writing "one million two hundred thirty four thousand five hundred sixty seven and eighty nine hundreths" as 1,234,567.89 or 1234567.89 or 1.234.567,89 (in parts of the world that use periods and commas the opposite of the way the US does).

      I suggest you've never seen an actual memory dump from a real computer, have you? Here's one I took just now on my Windows box. Which of these values are integers, floating point values, x86 opcodes or BCD values? Memory dumps don't indicate, because the memory itself doesn't know! Once it's in memory it's all just bits!

    65. Re:Some kind of... by Anonymous Coward · · Score: 0

      or if binary itself is a bug.

      concept of binary #isabug

      #if

    66. Re:Some kind of... by xouumalperxe · · Score: 1

      No. clon53421... 0x10 is 10000 in binary which is 16 in DECIMAL the "0x" part means hexadecimal. You cannot have "16 in binary" because binary only has ones and zeros.

      0x10 is hexadecimal and is a common representation for the byte 0001 0000. This byte can either represent 16 (if you assume binary encoding) or 10 (if you assume BCD encoding), or even the DLE character if you assume ASCII encoding. Why is it so hard to separate internal representation from encoding, folks?

    67. Re:Some kind of... by Anonymous Coward · · Score: 0

      i think he meant hexadecimal

    68. Re:Some kind of... by Anonymous Coward · · Score: 0

      ORLY. How about that.

      I thought the fail in this thread was strong, but it just keeps getting stronger. If this continues, then by 2011 Slashdot will be entirely dedicated to arguments about the decimal values of small binary numbers when various obscure encodings are used. "101 is 36 in binary!" is the new goatse.cx.

    69. Re:Some kind of... by Vintermann · · Score: 4, 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.

      --
      xkcd is not in the sudoers file. This incident will be reported.
    70. Re:Some kind of... by Jane+Q.+Public · · Score: 1

      Yes it does designate the encoding. At least in software. If you are talking about the hardware representation of the number, you should say so. That is a different matter entirely. And also almost totally irrelevant, since nobody has made computers that use BCD for decades now.

      And your little memory dump means nothing. The memory doesn't have to "know" what it represents. Why should it? That's not what I stated.

      What I wrote was that the binary representation of a set of numbers will look different when shown as BCD as opposed to hexadecimal. There will be different values displayed on the screen. I did not write that glancing at a memory dump will tell me whether it was BCD or hex. What I stated was that they will look different... and they will. Try it yourself. Take 3 random integers from 1 to 10,000, write them out as BCD or hexadecimal, and try to tell me that the ones and zeros are all the same between the two sets. Hint: they aren't.

      What I stated was that IF that screen dump represented numbers, the values you see printed on the screen would be DIFFERENT, depending on whether the values to be displayed are represented as BCD or hex. Don't get confused now... I am fully aware that they are being displayed as hex (and ASCII). But if they were stored in memory as BCD, the hex and ASCII values you see displayed would not be the same.

      There is nothing preventing you from "suspecting" anything you want, but you are still wrong.

    71. Re:Some kind of... by Jane+Q.+Public · · Score: 1

      "nobody has made computers that use BCD for decades now"

      Clarification: What I meant was that nobody makes computers that use BCD for internal (hardware) representation anymore. It is way too inefficient.

    72. Re:Some kind of... by rvw · · Score: 1

      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!

      He wasn't using base 2, but base-hand, you know, the one that counts up to 1111111111. It's favorite among toddlers.

    73. Re:Some kind of... by Anonymous Coward · · Score: 0

      Actually there are two to the seven billionth power types of people in this world.

    74. Re:Some kind of... by eugene_roux · · Score: 1

      Ah... But there are 11 (binary) types of people! Or put in another way, there are 10 types of people:

      Those who understand it,
      those who don't and
      those who ask: "What the fsck is Ternary?!"

      --
      Part Time Philosopher, Oft Times Romantic, Full Time Unix Geek
    75. Re:Some kind of... by Mr+Z · · Score: 4, 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 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.

    76. Re:Some kind of... by Mr+Z · · Score: 1

      At least, not their default representation. There are plenty of computers that provide some amount of acceleration for BCD arithmetic, including every x86 box out there. :-) BCD arithmetic is still rather common in financial applications.

    77. Re:Some kind of... by Anonymous Coward · · Score: 0

      10_{2} = 2_{10} (10 is the binary representation of 2).

      1*2^1 + 0 *2^0 = 2.

      I'm glad we can all agree on this base conversion.

    78. Re:Some kind of... by mc6809e · · Score: 1

      Yes it does designate the encoding. At least in software. If you are talking about the hardware representation of the number, you should say so. That is a different matter entirely. And also almost totally irrelevant, since nobody has made computers that use BCD for decades now.

      Well, I'm not sure what you mean exactly by "computers that use BCD", but I know that many processors DO support BCD, including any x86 compatible processor and 8051 based systems used in many embedded applications. And Intel thought that BCD support was important enough that they made BCD vector instructions are available when they added SIMD support.

    79. Re:Some kind of... by jc42 · · Score: 1

      There are 3 kinds of people in the world; those that can count and those that can't.

      I much prefer it with "don't" rather than "can't", since that produces an ambiguity between a literal and an idiomatic reading, further confusing the reader as to what you meant.

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
    80. Re:Some kind of... by Anonymous Coward · · Score: 0

      BCD is an encoding. That means it maps a set of values to another set of values. How you specify either side of the mapping is irrelevant. 0x10 is a hexadecimal literal representation of the decimal number 16. BCD encoding the decimal number 10 (hexadecimal a, binary 1010) results in the binary number 00010000, which is the same as the decimal number 16 and the hexadecimal number 0x10. The hexadecimal representation of a BCD encoded value has the same digits as the original decimal value, which means that if you look at a BCD number in a hex editor, you can immediately read the decimal digits.

    81. Re:Some kind of... by Jane+Q.+Public · · Score: 1

      Yes that's true. I didn't mean that they can't use BCD, but it's not the default for anything that I am aware of.

      And the reason some financial software still uses BCD is exactly the same reason that some financial software is still in COBOL.

    82. Re:Some kind of... by brianosaurus · · Score: 1

      If its unary, isn't the token used irrelevant?

      --
      blog
    83. Re:Some kind of... by Anonymous Coward · · Score: 0

      No. No. No.

      0x10 is 16 in hex, just as 0xf is 15 in hex. 0x10 is not a binary number, no more than 0xe is a binary number. Binary cannot ever, ever, under any circumstance contain any digit other than 0 or 1. Thus, 0x10 is not, nor will it ever be a binary number when written as 0x10.

      Binary 0010 is two. One could leave off the leading zeroes and say 10 is two, but that is not 0x10 now is it?

    84. Re:Some kind of... by methamorph · · Score: 1

      There are 10 kinds of people. Those who understand binary and those who dont.

    85. Re:Some kind of... by Anonymous Coward · · Score: 0

      unary would use only zeroes :)

      Unary has no significant zeros. It is simply tic marks that each equal to one. 11111 = 5. 110 = DNE.

    86. Re:Some kind of... by Anonymous Coward · · Score: 0

      appending a 0x

      would give 100x. You mean 'prepending'.

      Ugh. No. He means "prefixing".

      "Prepending" is an abomination of a word.

    87. Re:Some kind of... by Anonymous Coward · · Score: 0

      I've just read http://en.wikipedia.org/wiki/Binary-coded_decimal

      Jesus Christ. No wonder shit gets fucked up. I always thought obfuscation for improving job security in computer science was a wink-wink kind of thing.
      But it's actually a fucking philosophy.

    88. Re:Some kind of... by kalidasa · · Score: 1

      Hey, what did you do the last time you realized you said something unbelievably stupid on the internet? Oh, right, post as an anonymous coward!

    89. Re:Some kind of... by kalidasa · · Score: 1

      From what I remember, Excel also thinks that February 29, 2000 doesn't exist.

    90. Re:Some kind of... by dkh2 · · Score: 1

      There are 10 kinds of engineers.

      Those who understand binary math,
      and those who don't.

      --
      My office has been taken over by iPod people.
    91. Re:Some kind of... by dkh2 · · Score: 1

      ROFLcopters! This is fixed in Excel 2007.

      --
      My office has been taken over by iPod people.
    92. Re:Some kind of... by jonbryce · · Score: 1

      It has no problem with 29th February 2009 in Excel 2003. The problem is that it thinks that 29th February 1900 is a valid date. That might be what you are thinking of.

    93. Re:Some kind of... by Anonymous Coward · · Score: 0

      Just because memory is cheap now doesn't mean that it has always been cheap. BCD is a sort of string representation, capable of arbitrary precision, but instead of wasting one byte per digit, it stores two digits per byte. Parsing strings into BCD numbers is trivial and converting BCD numbers back into strings is also trivial. These days many programmers do not understand how anything below the C level works, but that doesn't mean that there is no point to all low level encodings but the ones which map directly to C types.

    94. Re:Some kind of... by bwcbwc · · Score: 1

      Who needs binary floats or BCD? 1024-bit integers do the trick just fine!

      --
      We are the 198 proof..
    95. Re:Some kind of... by bwcbwc · · Score: 1

      Only if the designers encoded a 2 DIGIT YEAR, even after y2K. otherwise it would be 3216 instead of 2010. I would hope that they weren't that stupid.

      --
      We are the 198 proof..
    96. Re:Some kind of... by HeadSoft · · Score: 1

      Encoding dates as hexadecimal, perhaps? For instance, encoding Christmas 2009 as 0x122509 - the lower nybble/year is 9. Make it 0x010110 - New Year's Day 2010, and the lower nybble is now 16.

    97. Re:Some kind of... by HeadSoft · · Score: 1

      Encoding dates as hexadecimal, perhaps? For instance, encoding Christmas 2009 as 0x122509 - the lower nybble/year is 9. Make it 0x010110 - New Year's Day 2010, and the lower nybble is now 16.

      I correct myself, I really should have said byte.

    98. Re:Some kind of... by whoisisis · · Score: 1

      in general, 10 in a base, b, is equal to b because it is equal to 1*b^1 + 0*b^0 = b.

    99. Re:Some kind of... by ikegami · · Score: 1

      When he said binary, he meant 2's complement

      byte 09 hex = 9 if BCD, 9 if 2's complement
      byte 10 hex = 10 if BCD, 16 if 2's complement

    100. Re:Some kind of... by ta+bu+shi+da+yu · · Score: 1

      Oops.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    101. Re:Some kind of... by Anonymous Coward · · Score: 0

      This is making me want to quit programming again.

    102. Re:Some kind of... by clone53421 · · Score: 1

      Thank you.

      In a computer, 0x10 is just a bit pattern. It can mean anything you want it to mean. As a binary integer, it means 16. As a BCD value, it means 10. In ASCII, it is the DLE character. In a 32-bit executable, it can be an opcode for ADC. In a picture, it could be a pixel with a colour defined by the 16th palette entry. In an ENUM field in a database, 0x10 could literally mean anything.

      It is up to the software to determine the correct meaning of 0x10 based on the rules that you set up. As the year field of an SMS message, it means 2010.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    103. Re:Some kind of... by ta+bu+shi+da+yu · · Score: 1

      Well, to be more precise, the 0x denotes that the notation being used signifies hexadecimal. There is no such thing as '16' in binary :-)

      --
      XML is like violence. If it doesn't solve the problem, use more.
    104. Re:Some kind of... by clone53421 · · Score: 1

      Yes it does designate the encoding. At least in software.

      [Citation Needed]

      If I am writing in embedded C, and I need a BCD constant in my program, I have to use the 0x prefix. Doing anything else would be stupid.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    105. Re:Some kind of... by clone53421 · · Score: 1

      Your first paragraph is just plain wrong.

      the decimal number 10 and the BCD number 0001 0000 would be incorrectly written in hexadecimal as 0x10.

      No. The decimal number 10, in BCD, is expressed as 0001 0000 (binary) or 0x10 (hexadecimal). If you are writing a C program for an embedded application, you could correctly write the following:

      a = 0x10; // BCD value

      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.

      No, the correct value is 0x10. It is specified in the SMS standard that the date is an 8-bit packed BCD value. The problem was that they decoded the value as if it was a standard binary number rather than a BCD number.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    106. Re:Some kind of... by clone53421 · · Score: 1

      There is no problem with using a 2-digit year if the lifespan of the data will be much, much less than 100 years.

      Sure, it’s ambiguous. This SMS says it was sent in the year “10”... does it mean 2010? or 1910? or perhaps it was sent from the year 2110? Gee... how will I ever figure that out...

      In the rare, rare occasion where you’d need to store an SMS for more than 100 years and be able to determine conclusively, without any context, what year it was sent in, store it as something other than an SMS that is able to hold this extra data.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    107. Re:Some kind of... by Anonymous Coward · · Score: 0

      You don't need retarded 4 bits per digit BCD for that. Just count thousandths of a number in ordinary binary.

    108. Re:Some kind of... by Anonymous Coward · · Score: 0

      appending a 0x

      would give 100x. You mean 'prepending'.

      Ugh. No. He means "prefixing".

      "Prepending" is an abomination of a word.

      Ugh. No. He means "prefacing".

      "Prefixing" is an abomination of a word.

    109. Re:Some kind of... by Anonymous Coward · · Score: 0

      No, no, no
      Digitocentrism must die, really.

      This is exactly what three-fingered aliens would say about your BCD FPUs:
      101/10 should be exactly 10.1 not 3.333333333333333

      BCD is a solution to the wrong problem. Alas, your bosses and customers stupidity doesn't have a technical solution for now.

      More bits means more precision for floating point representations, period. that 1 after the whole bunch of 0s is the price you pay for a finite representation.

      With BCD you are using less bits and thus you are getting worse results for all divisions that don't involve powers of 10. IMO, anyone working on financial institutions who promotes BCD should be checked thrice, once by a psychiatrist and twice by the FBI.

    110. Re:Some kind of... by aminorex · · Score: 1

      > When you divide 1 by 10, you should get 0.1, not 0.10000000000000001

      Umm, no. You should get the IEEE-758 value closest to 0.1. Anything else is wrong. 0.1 is wrong.

      --
      -I like my women like I like my tea: green-
    111. Re:Some kind of... by Anonymous Coward · · Score: 0

      You sir, are a moron. BCD uses MORE bits. For example, 0xFFFF takes 2 bytes if stored in binary, and 5 nibbles (2,5 bytes) if stored in BCD (0011 0101 0101 0011 0101). And I can't see how 101/10 can equal 3.333333 by mistakingly using whatever system I know. It's 10.1 (BCD!), 2.5 (binary), 128.5 (hex) or 8.125 (oct). TFA is not about (im)precision of encoding systems, but about human error. So, about people making stupid errors like you.

    112. Re:Some kind of... by Anonymous Coward · · Score: 0

      I prefer "there are +- kinds of people in the world, those who understand balanced ternary and those who don't"

    113. Re:Some kind of... by Nazlfrag · · Score: 1

      There are in fact A kinds of people. Those who understand unary, binary, ternary, quaternary, quinary, senary, septenary, octal, nonary and decimal.

    114. Re:Some kind of... by Enter+the+Shoggoth · · Score: 2, 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 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"

      --
      Andy Warhol got it right / Everybody gets the limelight
      Andy Warhol got it wrong / Fifteen minutes is too long.
    115. Re:Some kind of... by ppanon · · Score: 1

      Why use BCD these days? It seems pretty silly to me. Why wouldn't you just use fixed point binary instead? i.e your unit is a cent (or 1/100 of a cent if you're a Microsoft DB) and you do integer calculations with those units. Then the position of your decimal place is just a representational nicety after base conversion. No 0.10000000000000001 will result.

      --
      Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
    116. Re:Some kind of... by BigMeanBear · · Score: 1

      Stardates are always expressed as floats, you insensitive clod!

      --
      += E
    117. Re:Some kind of... by TarMil · · Score: 1

      We're not talking about IEEE-754 (not 758 btw), we're talking about math. And in math, 1/10 = 0.1. Some systems require this result.

    118. Re:Some kind of... by Eraesr · · Score: 1

      Yeah and make the mistake of saving it as 32 bit int and run into trouble 7 years later

    119. Re:Some kind of... by Vintermann · · Score: 1

      Tell that to accountants.

      --
      xkcd is not in the sudoers file. This incident will be reported.
    120. Re:Some kind of... by Vintermann · · Score: 1

      That is an option for most cases I know. I know the fixed point decimal type of Ada works this way, and probably the one in COBOL as well.

      But I assume the database vendors know what they are doing, and they seem to assume true floating point decimal is needed, not just fixed point.

      For more than you would ever want to know about the issue, I recommend Mike Cowlishaw's FAQ:

      http://speleotrove.com/decimal/decifaq.html

      --
      xkcd is not in the sudoers file. This incident will be reported.
    121. Re:Some kind of... by Anonymous Coward · · Score: 0

      Then the position of your decimal place is just a representational nicety after base conversion.

      It's not just a 'representational nicety'. You have to keep track of the decimal point and do manual rounding/shifting. If you have (say) two 3-digit fixed decimals maybe representing a x.yy currency amount and an a.bb interest rate and multiply them, you will end up with a six digit fixed result which you have to interpret as cc.dddd and probably manually round to cc.ee. If you do all this with BCD operands defined with the correct number of decimal places this will all be taken care of consistently and automatically.
      (It doesn't help even if you use cents etc. at your currency units. Interest calculations etc. will still result in fractions of cents which you have to deal with manually for rounding/shifting; and if you use cents as your base you will have to remember to convert inputs and outputs; you forget once and now all calculations are suspect).

    122. Re:Some kind of... by Anonymous Coward · · Score: 0

      poor choice
      there are 2 kinds of people
      those understand binary 1
      those who don't 0
      10 = 2
      11 = 3 doesn't fit in here

    123. Re:Some kind of... by Jake+Griffin · · Score: 1

      appending a 0x

      would give 100x. You mean 'prepending'.

      Ugh. No. He means "prefixing".

      "Prepending" is an abomination of a word.

      Ugh. No. He means "prefacing".

      "Prefixing" is an abomination of a word.

      Actually, all three (prepending, prefixing, and prefacing) are words, but "prefacing" doesn't make sense in this case. Prefacing is supposed to be used in the sense of "prefacing a book," which is adding what is also known as a "foreword" or "preface" and can be thought of as a "Chapter 0" of sorts. However, you cannot preface a word by adding letters to the beginning of it.

      --
      SIG FAULT: Post index out of bounds.
    124. Re:Some kind of... by Jake+Griffin · · Score: 1

      There are 11 kinds of people in the world, those who understand unary and those who don't.

      --
      SIG FAULT: Post index out of bounds.
    125. Re:Some kind of... by Jake+Griffin · · Score: 1

      There are actually 2^A kinds of people, because they can understand or not understand each of those systems. For example, I understand all of them. I am not "all ten types", I am one type. I am the type that understands all ".........." or "1010" or "101" or "22" or "20" or "14" or "13" or "12" or "11" or "10" of them.

      --
      SIG FAULT: Post index out of bounds.
    126. Re:Some kind of... by Jake+Griffin · · Score: 1

      Why would that code not be around in 2100 or 2256? Office 2007 still has code from the Dark Ages, so if it's already lasted hundreds of years, what's a few more?

      --
      SIG FAULT: Post index out of bounds.
    127. Re:Some kind of... by ppanon · · Score: 1

      But I assume the database vendors know what they are doing, and they seem to assume true floating point decimal is needed, not just fixed point.

      Funny but the money data type has been in Microsoft SQL Server since SQLSrvr2000, and there's at least one other. But yeah, Oracle currently only supports BCD-style Numeric(). Of course there's a lot of non-financial data that's better suited to floating point.

      But the important point is that, unless you've got infinite memory to hold repeating decimal places (such as when you divide by 3), at the end of the day, you're still going to be doing some kind of rounding off with BCDs as much as with fixed point binary. Yeah, there's maybe a little more work in using integer ops to do fixed points than there is with floating point, but it's going to be way faster than BCD calculations. If you're smart, you use a language or a compiler that allows you to hide most of that. For nearly all financial transactions, money is a fixed point value, and you can deal with it appropriately that way in decimal or binary arithmetic.

      --
      Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
    128. Re:Some kind of... by Trogre · · Score: 1

      I suspect GP meant EBCDIC specifically.

      --
      "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
    129. Re:Some kind of... by Darth_RayDar · · Score: 1

      I bet it was someone at a console in a server room on New Year's Eve given the task of incrementing the hexadecimal year on the dot of midnight. One can too many and all he could think of was "nine plus one ... put down the nought and carry the one". Thus 7d9 (2009) + 1 = 7e0 (2016) instead of 7da (2010). He's probably well sobbered up by now.

    130. Re:Some kind of... by LostCluster · · Score: 1

      So that means the root cause would be taking a hex 2-digit value and doing integer math and then reading the result as if it was still hex. The correct value would have been 0x0a.

    131. Re:Some kind of... by Hognoxious · · Score: 1

      They should have read the specs instead to learn it was BCD

      Or even, you know, tested it.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    132. Re:Some kind of... by Hognoxious · · Score: 1

      It's not just a 'representational nicety'. You have to keep track of the decimal point and do manual rounding/shifting.

      It's not that difficult. SAP works like that (possibly so it can cope with currencies and units that have different numbers of decimal places).

      It doesn't help even if you use cents etc. at your currency units. Interest calculations etc. will still result in fractions of cents which you have to deal with manually for rounding/shifting

      It does help, because anything less than a cent automatically drops off the right. It does mean that you occasionally have to take care with the sequence of calculations, especially if there's division going on.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    133. Re:Some kind of... by Ciggy · · Score: 1
      Mefinx you mean 0xFFFF = 0110 0101 0101 0011 0101 in BCD?

      Whatever the base (>= 2), 101 / 10 is *ALWAYS* 10.1 in that base.

      Shirley you made sum mishtake:
      • binary -> decimal: 10.1 -> 2.5
      • octal -> decimal: 10.1 -> 8.125
      • hexadecimal -> decimal: 10.1 -> 16.0625

      I'd love to know in what base 10.1 converts to 128.5 in decimal. (It can't be base 128 as implied by 10 => 128, similarly it can't be 2 as implied by .1 => .5 = 1/2)

      Mefinx you also missed a base:

      • base 3 -> decimal: 10.1 -> 3.33....

      In fact for any base not of the form "(2^m)(5^n)" any [proper] rational fraction in that base is a recurring decimal (in base 10); thus 0.1 in base 3 is 1/3 in decimal and is a recurring fraction in decimal.

      Similarly, any fraction that is not of the form m/(2^n) in decimal is recurring in binary and cannot be represented exactly; 0.1 in decimal = 1/10 which is NOT of the form m/(2^n) and thus cannot be exactly represented in binary - it is in fact 0.0001 1001 1001... (or in hexadecimal (for easier reading): 0.199...) and so will introduce rounding errors.

      Talk about stupid errors...

      --

      A rose by any other name would smell as sweet;
      A chrysanthemum by any other name would be easier to spell
    134. Re:Some kind of... by Muad'Dave · · Score: 1

      I'd love to know in what base 10.1 converts to 128.5 in decimal.

      In general, 10.1 in any base x is x + 1/x.
      Simplifying x + 1/x = 128.5 gives x^2 - 128.5x + 1 = 0 which yields (approximately) 0.0077826 and 128.49.

      Thanks for giving me a reason to recall the quadratic equation!

      --
      Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
    135. Re:Some kind of... by Anonymous Coward · · Score: 0

      Wow. All this arguing about what value 0x10 represents... it's a perfect demonstration of how these bugs come to be....

    136. Re:Some kind of... by Anonymous Coward · · Score: 0

      ...is like saying $10 = £10, which just isn't so.

      From my observation of computing literature, that seems to be fairly accurate; along with computer programs.

    137. Re:Some kind of... by Christoffer777 · · Score: 1

      Take it easy on him. After all, there are only 10 kinds of people in this world.

      Actually, I would argue that there are 11 kinds of people in this world. Those that understand binary, those that do not and finally those that don't care.

    138. Re:Some kind of... by geminidomino · · Score: 1

      It has no problem with 29th February 2009 in Excel 2003. The problem is that it thinks that 29th February 1900 is a valid date. That might be what you are thinking of.

      It might also be a problem (if by "it has no problem" you mean "it accepts") that it things that February 29, 2009 is a valid date...

  3. 4-bit years? by Anonymous Coward · · Score: 2, Insightful

    A 4-bit year field? Wrapping from 9 to 0 (16) ?

    1. Re:4-bit years? by Midnight+Thunder · · Score: 1

      A 4-bit year field? Wrapping from 9 to 0 (16) ?

      I should hope not, otherwise it shows that either people forgot about Y2K very fast or underestimated the issues of their short-sightedness.

      --
      Jumpstart the tartan drive.
    2. Re:4-bit years? by Anonymous Coward · · Score: 0

      probably
      this was no doubt caused by a fix implemented for the year 2000 way back
      They probably have the first two numbers in one column
      the other 2 of the year in a second column.
      both stored or interpretted differently
      This probably wasnt turned on until January 1st 2000 thus averting the 0x99 figure which clearly would have shown this bug back then.

      Thus the lazy testers didnt test 1999 as a date and skipped straight to 2000.

  4. Microsoft by sopssa · · Score: 5, Informative

    Seems Microsoft is supplying some code for EFTPOS machines that is common with Windows Mobile, so it's most likely the same bug in both.

    1. Re:Microsoft by mspohr · · Score: 1

      People run Microsoft software on EFTPOS / ATM machines?

      --
      I don't read your sig. Why are you reading mine?
    2. Re:Microsoft by sopssa · · Score: 3, Informative

      Yes they do (almost in every atm actually).

    3. Re:Microsoft by Anonymous Coward · · Score: 0

      And that is after they "upgraded" from OS/2 which used to be quite frequently used on ATM's:
      http://en.wikipedia.org/wiki/OS/2#ATMs

    4. Re:Microsoft by witherstaff · · Score: 1

      Cool, any way to figure out what ATMs think it's the future? I'd like to do a big withdraw now and worry about paying it back sometime in the next 6 years.

    5. Re:Microsoft by misterduffy · · Score: 1

      nearly all the POS systems i've worked with ran NT. is it possible the systems affected in this instance have some legacy NT code? is it possible windows mobile has some legacy NT code?? now *that* would be embarrassing...

    6. Re:Microsoft by Myopic · · Score: 1

      Oh, yes! I was using an ATM one time and it crashed, straight up crashed, like blue-screen-of-death-style crashed. It blinked off and automatically rebooted, and I excitedly thought to try to give it input during the boot sequence (pure shenanigans). But as you would hope, nothing I pressed had any effect. It booted, showed a desktop (which was very weird on an ATM screen), then automatically started the ATM software, which then showed me the main ATM screen. I got cash.

    7. Re:Microsoft by ElDaffo · · Score: 1

      This wouldn't be Microsoft's first date related blunder. Did anyone ever experience the excel date quirk? Apparently MS didn't realise 1900 wasn't a leap year. A by product of this is that your dates gain 4 years if you open them on Mac Office. What about the Zune's effort with the 366th day of 2008? Although I think this just requires a different marketing strategy, a mobile email device that can help me travel into the future? I'll take two please.

    8. Re:Microsoft by Cederic · · Score: 1

      I got cash.

      All stories should end like this.

    9. Re:Microsoft by Jake+Griffin · · Score: 1

      By POS, do you mean "Piece Of ****" or "Point Of Sale"? I always got a laugh when people called the register at a place I worked "the POS" because I didn't know that it stood for "Point of Sale"...

      --
      SIG FAULT: Post index out of bounds.
    10. Re:Microsoft by bertok · · Score: 1

      This wouldn't be Microsoft's first date related blunder. Did anyone ever experience the excel date quirk? Apparently MS didn't realise 1900 wasn't a leap year. A by product of this is that your dates gain 4 years if you open them on Mac Office. What about the Zune's effort with the 366th day of 2008?
      Although I think this just requires a different marketing strategy, a mobile email device that can help me travel into the future? I'll take two please.

      All joking aside, that's not a bug, that's a feature.

      Reading about the details behind such things can reduce a grown programmer to tears. (the bit about 1900 issue is towards the middle)

    11. Re:Microsoft by Anonymous Coward · · Score: 0

      Dunno what PC World uses now, but when it was set up (by VT before it was sold out to DSG) it used SCO (the original, not the current fake encumbants TSG) Xenix running on Tandon 0x86 computers.

  5. My wireless landline phones all failed 1/1/2010 by Gorobei · · Score: 4, Interesting

    No dial tone, no incoming calls.

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

    1. Re:My wireless landline phones all failed 1/1/2010 by Skapare · · Score: 1

      Be glad it wasn't fetching dates from upstream somewhere. But at least you now know these devices are designed to become obsolete sometime between now and 2016.

      --
      now we need to go OSS in diesel cars
    2. Re:My wireless landline phones all failed 1/1/2010 by Chapter80 · · Score: 1

      Had to reset the internal datetimes back to 2007

      Not sure your phone uses "day of week" at all, but if so, consider winding the clock back to 1999 (the last year that January 3 was on a Sunday) or 1982 (the last year that 1/3 was on a Sunday AND we were two years into the 4-year leap-year cycle).

      You're going to have another problem in 3 years (when your phone thinks it's 2010 again), so at the very least you may want to go back to 2000 and buy yourself ten years.

    3. Re:My wireless landline phones all failed 1/1/2010 by Anonymous Coward · · Score: 0

      If he has caller ID he may run into trouble next time someone calls as the clock will be automatically reset.

    4. Re:My wireless landline phones all failed 1/1/2010 by aminorex · · Score: 1

      WinCE I am guessing.

      --
      -I like my women like I like my tea: green-
  6. Text messaging from the future by nurhussein · · Score: 3, Funny

    Imagine that, the ability to text to the past. We could get warnings about impending events! New Text Message From Marty McFly: I HV TO TELL U ABT TEH FUTURE Reply from Doc Brown: WHAT? New Text Message From Marty McFly ON THE NIGHT YOU GO BACK, YOU GET SH*message text missing*

    1. Re:Text messaging from the future by sirkha · · Score: 1

      Hmm, I guess that means the world doesn't end in 2012, then. Or maybe it does end in 2012, and it took them 4 years to devise their time-traveling SMS, and are now desperately trying to let us know.

  7. 10 hex is 16 decimal by Anonymous Coward · · 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.

    1. Re:10 hex is 16 decimal by nycguy · · Score: 5, Informative

      This is almost certainly what it is. The year is stored in an SMS message as a two-digit BCD value, according to this spec. (Click on the link for the "timestamp" field.) Some phones must be treating it as a hex field. (Note that most other fields in the SMS message are in hex.)

    2. Re:10 hex is 16 decimal by Anonymous Coward · · Score: 1, Insightful

      nycguy gets 100 points. Thread closed.

    3. Re:10 hex is 16 decimal by camperdave · · Score: 1

      I thought the whole Y2K fiasco taught people not to use two digits to represent years. Am I the only one who learned that lesson?

      --
      When our name is on the back of your car, we're behind you all the way!
    4. Re:10 hex is 16 decimal by Skapare · · Score: 1

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

      --
      now we need to go OSS in diesel cars
    5. Re:10 hex is 16 decimal by Anonymous Coward · · Score: 0

      Second that

    6. Re:10 hex is 16 decimal by Anonymous Coward · · Score: 1, Funny

      >I plan to be retired by then, so I don't care.

      Quitter!

    7. Re:10 hex is 16 decimal by Anonymous Coward · · Score: 0

      Wow, close one with the string parsing. Some people actually use string parsing to convert an integer to BCD. From an SMS handling project on Google Code:

      octets[type] = Integer.parseInt("" + value, 16);

      Ouch.

    8. Re:10 hex is 16 decimal by camperdave · · Score: 1

      Two digits is fine, now

      Apparently not.

      --
      When our name is on the back of your car, we're behind you all the way!
    9. Re:10 hex is 16 decimal by Posting=!Working · · Score: 3, 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?

      --
      This sentence no verb.
    10. Re:10 hex is 16 decimal by Anonymous Coward · · 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.

    11. Re:10 hex is 16 decimal by clone53421 · · Score: 1

      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 method breaks down is when you’re calculating the date of an SMS that’s over 100 years old.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    12. Re:10 hex is 16 decimal by Pembers · · Score: 4, 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.

    13. Re:10 hex is 16 decimal by clone53421 · · Score: 2, Informative

      It makes a lot more sense in little endian.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    14. Re:10 hex is 16 decimal by ArsenneLupin · · Score: 1

      Two digits is fine, now ... until we approach 2100.

      Wrong. It's only fine until we approach 2010. "Microsoft... nothing is impossible!"

    15. Re:10 hex is 16 decimal by Anonymous Coward · · Score: 0

      Also shows that the code fragment must be quite recent vintage. The SMS spec has been around for a while, and nobody got confused when it wrapped up from "99" to "00".

      Neither do I recall any SMS from 1999 showing up as 19153.

    16. Re:10 hex is 16 decimal by Megane · · Score: 1

      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.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    17. Re:10 hex is 16 decimal by Bigjeff5 · · Score: 1

      Worse, it's a specification issue with SMS, which predates the lessons learned from Y2K by years.

      So we'll need the industry to agree to an ammendment to the spec. Until then you'll see hacks in phones like "if year = 2016, year = 2010" to bandaid it. Hopefully they remember to change it after 2010 and don't leave the hack in until 2016 rolls around.

      --
      Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
    18. Re:10 hex is 16 decimal by Vintermann · · Score: 3, Funny

      > what sort of idiot would try to fit a message into 160 characters?

      If we find the answer, twitter will finally make sense.

      --
      xkcd is not in the sudoers file. This incident will be reported.
    19. Re:10 hex is 16 decimal by Anonymous Coward · · 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.

    20. Re:10 hex is 16 decimal by Anonymous Coward · · Score: 0

      The spec says it's the last two digits of the year as a BCD value with the nibbles swapped. Other than the fact that that's a funky number format, there's nothing wrong with it. Two digits is plenty for an instant message. If you need a normal binary representation, that would be
      year = 10*(sbcd & 15) + (sbcd >> 4);
      year += ((yearCur + 50 - year) / 100) * 100;

      But obviously writing "year = 2000 + sbcd;" and complaining about the spec is simpler.

    21. Re:10 hex is 16 decimal by Megane · · Score: 2, 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 situation where you are keeping old data for years and years, nor are you doing date arithmetic or sorting of 50+ years range, not even ten years. Nobody's birthdate will be in the timestamp of an SMS message, nor will the expiration date of their credit card. As a timestamp, the century is explicitly implied* by context, the context being that of the calendar that's hanging on the wall of your cubicle.

      If someone were to make a database with years of SMS messages and not include the century as messages were added to the database, then yes, that would be a problem. But it would not be a problem with the SMS message format. When the year 2100 rolls around, and assuming we're even still using SMS, the worst that would happen is "hundred year old" text messages. At least then the low two digits would still be right, unlike the current "2016" stupidity.

      *that's an awesome combination of words

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    22. Re:10 hex is 16 decimal by kilodelta · · Score: 1

      I think you're on to something. I wonder why it hasn't hit the U.S. yet.

    23. Re:10 hex is 16 decimal by osu-neko · · Score: 1

      ...and thought it was useless - what sort of idiot would try to fit a message into 160 characters?

      Ah, the classic error. Remember, no one has ever gone broke underestimating the intelligence of the public. (IIRC, in the original quote it was "taste", but whatever...) Point being, "idiots" is a very, very large and profitable target for marketing products to.

      --
      "Convictions are more dangerous enemies of truth than lies."
    24. Re:10 hex is 16 decimal by hawk · · Score: 2, 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

    25. Re:10 hex is 16 decimal by The_reformant · · Score: 1

      He meant 2100 in hex. :)

      --
      I have discovered a truly remarkable sig which this post is too small to contain.
    26. Re:10 hex is 16 decimal by Anonymous Coward · · Score: 1, Informative

      But IS it harder to read? For a human, yes. But, for a computer this makes perfect sense for a little endian computer. On a little endian machine (i.e. Intel x86), the bytes are stored sequentially from memory address zero up. If you grab large a 32-bit number and print it, you might see would see x0000000F. This makes things very easy for computer because a small number can be read from the same address as a 8 bit, 16 bit, and up without any need to adjust the offset (i.e. 0F = 15, 0F00 = 15, 0F000000 = 15). A big endian machine will make things follow Arabic numerals (i.e. 0F = 15, 000F = 15, 0000000F = 15). To correctly read a number, you have to adjust your offset to match the size of your number.

      Now, we can also think about these mindsets when dealing with nibbles. A swapped nibble set means that for a computer each BCD encoded number becomes directly addressable on a little-ending machine straight up through memory. All I have to know is starting byte and the number of digits so I know when to stop. Fifteen years ago, saving code space was more important than being human readable. Swapped nibble encoding meant a simple algorithm to get each decimal:

      byte_address = byte_address_start + decimal_count >> 2
      byte = *byte_address -> byte_type
      decimal = decimal_count mod 2 ? byte AND F0 >> 4 : byte AND 0F

      Some machines have instructions in the processor to handle this type of behavior innately.

    27. Re:10 hex is 16 decimal by Anonymous Coward · · Score: 0

      But endianess effects byte order, not nibble order! Unless someone redefined a byte as 4 bits for this system...

    28. Re:10 hex is 16 decimal by bakes · · Score: 1

      what sort of idiot would try to fit a message into 160 characters

      Don't know. Pls get milk on yr way home.

      --
      Ho! Haha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!
    29. Re:10 hex is 16 decimal by twosat · · Score: 1

      Surely it's "nybble" not "nibble", next thing we will be talking about "bites" instead of "bytes"!!

    30. Re:10 hex is 16 decimal by clone53421 · · Score: 1

      But endianess effects byte order, not nibble order!

      ...Which is why it makes more sense to swap the nibbles.

      0x1234CDEF gets stored in memory as 0xEFCD3412, if you’re reading from low address to high address.

      If you swap the nibble order, you store it as 0xFEDC4321, which makes it easier to read a memory dump.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    31. Re:10 hex is 16 decimal by caller9 · · Score: 1

      It is 160 characters because of one guy and his typewriter in 1985.

      http://latimesblogs.latimes.com/technology/2009/05/invented-text-messaging.html

      "Alone in a room in his home in Bonn, Germany, Friedhelm Hillebrand sat at his typewriter, tapping out random sentences and questions on a sheet of paper.

      As he went along, Hillebrand counted the number of letters, numbers, punctuation marks and spaces on the page. Each blurb ran on for a line or two and nearly always clocked in under 160 characters."

    32. Re:10 hex is 16 decimal by Anonymous Coward · · Score: 0

      Why didn't we see these kind of problems back in the 90s? ie 0x99 = 153
      SMS was around then.

    33. Re:10 hex is 16 decimal by Anonymous Coward · · Score: 0

      That is most certainly a fabrication. In the beginning, the technical facility which is now known as SMS wasn't even used for readable text messages. It was designed for sending configuration information, and it is still used for that purpose today. SMS were not billed until people discovered that they could send text messages for free and network operators discovered that that may be a viable product. Before that, it was not a marketed feature at all.

    34. Re:10 hex is 16 decimal by Anonymous Coward · · Score: 0

      The affected phones probably had their software written some time after 2000.

  8. Future SMS by fireflake · · Score: 0

    Quick, someone send an sms to the future and ask if they solved the climate change problem.

    1. Re:Future SMS by Anonymous Coward · · Score: 0, Troll

      The future replied back saying that climate change was a hoax and that Al Gore is now broke holding worthless carbon credits.

    2. Re:Future SMS by CharlyFoxtrot · · Score: 4, Funny

      I did but all they told me was that I talk like a fag and my shit's all retarded.

      --
      If all else fails, immortality can always be assured by spectacular error.
    3. Re:Future SMS by kesuki · · Score: 1

      greetings earthling the good news is PEOPLE are tasty, when the motherships get here it's like thanksgiving on steroids.
      (for the simple minded ones this is a joke)

    4. Re:Future SMS by Anonymous Coward · · Score: 0

      I TOLD you to stop acting like a retarded faggot! If I told you once, I told you a million times! Did you listen? HELL NO! You went whining to Mama all the time, and she coddled her retarded faggot baby!!

      Love,
      your brother,

      BravoFoxtrot

    5. Re:Future SMS by Runaway1956 · · Score: 4, 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!

      --
      "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
    6. Re:Future SMS by ae1294 · · Score: 1

      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.

    7. Re:Future SMS by mjwx · · Score: 1

      The future replied back saying that climate change was a hoax and that Al Gore is now broke holding worthless carbon credits.

      Our Cockroach overlords also want to thank us for making them the worlds dominant species.

      --
      Calling someone a "hater" only means you can not rationally rebut their argument.
    8. Re:Future SMS by Jerslan · · Score: 1

      One of my favorite comedies ever.

    9. Re:Future SMS by Genocaust · · Score: 1

      +1 Insightful

      --
      It could be that the only purpose of your life is to serve as a warning to others.
    10. Re:Future SMS by Anonymous Coward · · Score: 0

      Should have fed them a politician. Al Gore comes to mind.

      Or Bono.

      Msge to fleet command: Avoid the 3rd rock, the inhabitants are actually shit!

  9. Y2K16-Bug? by kju · · Score: 1

    It's a Y2K10-Bug. The Y2K-Bug was not titled Y1900-Bug (to name one of the bug types) as well.

    1. Re:Y2K16-Bug? by Simon+(S2) · · Score: 1

      Y2K10 would be 200010. Silly contractions...

      --
      I just don't trust anything that bleeds for five days and doesn't die.
    2. Re:Y2K16-Bug? by TeknoHog · · Score: 1

      Y2K10 would be 200010. Silly contractions...

      Then again, in electronics 2K10 would be parsed as 2.10 thousand, or 2100.

      --
      Escher was the first MC and Giger invented the HR department.
    3. Re:Y2K16-Bug? by MZeora · · Score: 1

      So... Y2K+10 would be more correct?

    4. Re:Y2K16-Bug? by Simon+(S2) · · Score: 1

      So... Y2K+10 would be more correct?

      Sure. But 2010 is shorter anyway (same for Y2K10), so why? Just write 2010...

      --
      I just don't trust anything that bleeds for five days and doesn't die.
    5. Re:Y2K16-Bug? by Opportunist · · Score: 1

      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 it!

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    6. Re:Y2K16-Bug? by Anonymous Coward · · Score: 0

      you could just call it an MMX bug.

      (1000+1000+10 = 2010)

    7. Re:Y2K16-Bug? by RealGrouchy · · Score: 1

      Either way, 2010 and 2016 are both shorter than Y2K10 or Y2K16, so the 'abbreviation' is absurd.

      - RG>

      --
      Hey pal, this isn't a pleasantforest, so don't waste my time with pleasantries!
    8. Re:Y2K16-Bug? by Anonymous Coward · · Score: 0

      So... Y2K+10 would be more correct?

      Sure. But 2010 is shorter anyway (same for Y2K10), so why?

      To kay ten, of course! (sorry, still a little festive).

    9. Re:Y2K16-Bug? by osu-neko · · Score: 1

      Either way, 2010 and 2016 are both shorter than Y2K10 or Y2K16, so the 'abbreviation' is absurd.

      Not really. It would be absurd if it was an abbreviation for the year alone. As a moniker for a particular kind of bug, it's quite concise and sensible. I think you'd be hard pressed to find a different five symbols that would convey both the nature of the bug and the time when it occurs instantly and unambiguously to any reader with even a passing knowledge of the subject, and most people, even laymen, know about the Y2K bug, at least well enough to follow what you're saying if it isn't overly technical.

      --
      "Convictions are more dangerous enemies of truth than lies."
    10. Re:Y2K16-Bug? by AK+Marc · · Score: 1

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

      And you'd be wrong. This problem wasn't addressed in Y2K because it was Y2K compliant. In fact, it's compliant for 2010 or 2016. It's that programmers are using different integer codings and converting wrong. That's unrelated to the problem of running out of digit space. This problem was created long before Y2K and wasn't fixed or worked on then, haphazardly or not. As it isn't a problem that would have happened if the programmers would RTFM.

    11. Re:Y2K16-Bug? by Anonymous Coward · · Score: 0

      No, Y2K10 would be Y2100, just as e.g. R4K4 = 4400 ohms

  10. Official explanation by Anonymous Coward · · 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.

    1. Re:Official explanation by Anonymous Coward · · Score: 0

      It's just that they're a bit slow up in Queensland. They've finally got around to having their Y2K bug. One day they might even have daylight savings.

  11. Its the LHC! by rescendent · · Score: 2, Funny

    The beam collisions have opened a portal into the future...

    1. Re:Its the LHC! by mewshi_nya · · Score: 1

      Huh, I always thought the LHC would cause a resonance cascade.

    2. Re:Its the LHC! by camperdave · · Score: 1

      I always thought the LHC would cause a resonance cascade.

      Yes, but a temporal resonance cascade. It can send people forward to 2016, or backwards to 1620, depending on your cell phone's software.

      --
      When our name is on the back of your car, we're behind you all the way!
    3. Re:Its the LHC! by Anonymous Coward · · Score: 0

      Typical, Windows (Mobile) only. No time travel for us Linux (Android) users! Tch!

    4. Re:Its the LHC! by Anonymous Coward · · Score: 0

      The beam collisions have opened a portal into the future...

      All things serve the beam.

  12. Worse: Re:Text messaging from the future by Anonymous Coward · · Score: 0

    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 prevent two trains from colliding because s/he saw it all in a newspaper and the name of the machinist was there and a friend that was once part of the geek squad was able to find the machinist's cell number and now that they know that 0x10 is 16 in HEX all they had to do is change the year on their cell phone and send an SMS: " your about to crash. alot more in next MSG"

    1. Re:Worse: Re:Text messaging from the future by ae1294 · · Score: 1

      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

  13. Function? by gmuslera · · Score: 1

    Start worrying about SMSs that warns about future events. The "avoid seeing that movie" sms could have been because a limited preview somewhere, but im still a bit worried about the "the alien landing on Jan 8 will be real" sms.

  14. * points finger at Duct Tape Programmers by amn108 · · 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?

    1. Re:* points finger at Duct Tape Programmers by daveime · · 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.

    2. Re:* points finger at Duct Tape Programmers by Blakey+Rat · · Score: 1

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

    3. Re:* points finger at Duct Tape Programmers by amn108 · · Score: 1

      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 seen the effects myself.

      That said, it does not have to be that either Joel or Jamie talk or do wrong. I am just acknowledging the dangers of using duct tape when not seeing how in the future things break and the "cost of ownership" rises. After all, this is a money industry too, right?

    4. Re:* points finger at Duct Tape Programmers by fnj · · Score: 1

      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.

    5. Re:* points finger at Duct Tape Programmers by benjamindees · · Score: 1

      You make it sound so bleak, as though there were only the two options. It is possible to build some things well so that they last a long time, and others not so much. The important thing is to keep them sufficiently separated, and to keep track of which is which so that you don't invest too much in something that will not last.

      One of my driers broke last week. A tree limb fell on it. A tree limb fell on it three years ago also. Last time it cost $10 to fix. This time it will cost $15. I will fix it, and keep using it, because it doesn't cost anything to operate, and is environmentally responsible. In the mean time, I will use the other one, the one that costs $50/yr to operate and runs on coal.

      --
      "I assumed blithely that there were no elves out there in the darkness"
    6. Re:* points finger at Duct Tape Programmers by Blakey+Rat · · Score: 2, 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 understand it. (Or, if they do now, future maintainers may not.) Basically, the coding equivalent to Keep It Simple, Stupid.

      2) The number one feature of any application is "it shipped." It doesn't matter how great your program is if it's vaporware.

      Neither of those two points have anything at all to do with this bug.

      The word "duct-tape" leads people to think that the philosophy has something to do with coding by the seat of your pants. "Oh this function isn't designed right, I'll just put a couple globals in this file to get the right params" or something like that. Not only is that not in the interview with Jamie, but even Joel's article doesn't say anything like that.

      When you choose a name like "duct-tape programmer" you're basically guaranteeing that people are going to misread the article, as I believe you have. Anyway, best to ignore that particular work of Joel's and go straight to the interview with Jamie in the first place, if you want the real story.

      This particular bug is simply a case of misreading a confusing spec in a subtle, and nobody catching it for years. That could happen regardless of your method or philosophy. Anybody coming into this and saying "oh unit tests would have nailed this!" or "oh that would never happen with Scrum!" is just cheerleading their favorite concept.

    7. Re:* points finger at Duct Tape Programmers by cfc-12 · · Score: 1

      I don't know, it seems to me that a bug like this could only have been introduced in the last ten years, which suggests less foresight than either of these types.

      Any code that works for 1999, 2009 and everything in between will probably work for 2010 as well. Code written since 2000 on the other hand might never have been tested with dates outside of the 00-09 range.

    8. Re:* points finger at Duct Tape Programmers by Anonymous Coward · · Score: 0

      As i understand it the 2032 is only a problem on a 32-bit Linux system. On a 64 bit Linux system there is no problem.

    9. Re:* points finger at Duct Tape Programmers by osu-neko · · Score: 1

      This has nothing to do with "duct-tape programming". It also has nothing to do with solutions that don't take the future into account. The SMS spec is perfectly fine, and most code that deals with it would work fine for the next million years if needed. The problem here is, someone never read the spec. "Not even reading the spec" is not an attribute of "duct-tape programming" in the Joel sense.

      --
      "Convictions are more dangerous enemies of truth than lies."
    10. Re:* points finger at Duct Tape Programmers by mibus · · Score: 1

      True "duct-tape programming" would bind an existing date datatype in (either YYYY-MM-DD HH:MM:SS, or seconds-since-1970).

      Duct-tape is not used to build new things, when there are existing things nearby that will do the job. It's used to hold existing things together! :)

    11. Re:* points finger at Duct Tape Programmers by broken_chaos · · Score: 1

      And hasn't that been patched in most, if not all, modern Unix systems? It's also a very well-known problem, so I'd think it would be patched on legacy systems sometime in the next 28 years...

    12. Re:* points finger at Duct Tape Programmers by Anonymous Coward · · Score: 0

      > There are 10 types of people ...

      > 1. Those who will make a solution [..]

      > 2. Those who will want to do unit tests [..]

      10. Those who will want to do unit tests [..]

      (Fixed that for you)

    13. Re:* points finger at Duct Tape Programmers by Anonymous Coward · · Score: 0

      Unit testing doesn't help a lick if you didn't interpret the spec correctly. You'll just end up with tests which prove your code does exactly what you thought you were doing, which turns out to be the wrong thing.

    14. Re:* points finger at Duct Tape Programmers by DNS-and-BIND · · Score: 1

      You missed the other eight types of people...? Where are they listed?

      Oh, you mean you were trying to be overly clever and speak in binary. In that case, the numbers of people would be 0. and 1. instead of 1. and 2. Good Lord save me from people who only repeat stuff that they've heard and have no idea of how it actually works.

      --
      Shutting down free speech with violence isn't fighting fascism. It IS fascism!
  15. You could mess with people! by olsmeister · · Score: 3, Funny

    Bob- Happy Nw Yr! What a decade so far. Cubs winning the series, and who would have predicted that the Mayan calendar was really right? Glad I loaded up on all the MSFT back in '10. Are you going to visit your wife's grave next week for the 6th anniversary? kthx!

    1. Re:You could mess with people! by __aasqbs9791 · · Score: 1

      You sir, are an evil, evil person. Also, your ideas are intriguing to me and I wish to subscribe to your newsletter.

    2. Re:You could mess with people! by ArsenneLupin · · Score: 1

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

  16. why even ONE digit? by r00t · · Score: 1

    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 1970), divide by 60, and throw away all but the low 8 bits. The receiver assumes this is in the recent past, unless it could fall within the future 5 minutes.

    1. Re:why even ONE digit? by pipatron · · Score: 1

      Too bad if your recipient turned off the phone during the night, ran out of batteries during a hike, or changed number temporary due to a trip abroad (roaming costs fucking sucks).

      --
      c++; /* this makes c bigger but returns the old value */
    2. Re:why even ONE digit? by Anonymous Coward · · Score: 0

      I need the full dates. I get status messages from monitoring scripts for an application I support on some servers, and get a few 'interesting' exceptions I like to keep for comparisons with comparable messages days or weeks later. Do not assume SMS is only for quicky social type messages - it is also a pager replacement in many IT shops.

      RO

    3. Re:why even ONE digit? by Bigjeff5 · · Score: 1

      I still don't see why they don't give a recieved timestamp, even if they still give a sent timestamp.

      --
      Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
    4. Re:why even ONE digit? by hitmark · · Score: 1

      my featurephone do, and that sometimes results in messages arriving before they are sent ;)

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    5. Re:why even ONE digit? by Anonymous Coward · · Score: 0

      What if I shut my phone off for over 4 hours?

    6. Re:why even ONE digit? by r00t · · Score: 1

      You're abusing something that wasn't meant for your purpose, and you're a weirdo. There is no reason why everybody else should pay any overhead for you.

      You can send your own date in the message itself.

    7. Re:why even ONE digit? by r00t · · Score: 1

      Yep.

      Getting a wrong time stamp on some rare occasion is no big deal.

      Throwing away old messages is another option, pretty reasonable too since they are most likely moot. (message "see you in a few minutes" for example)

      Of course, a 2-byte value would allow for about 2 months to deliver the message.

    8. Re:why even ONE digit? by Anonymous Coward · · Score: 0

      What about a message that my new fiance just sent to one of her friends? "I know you're in the mountains and won't get this til Tuesday, but I wanted to tell you the great news. Anonymous Coward proposed!!! Can't wait to see you!" Is that message moot and reasonable to throw away?

    9. Re:why even ONE digit? by Anonymous Coward · · Score: 0

      Yes, everybody knows that I didn't mean it. Throwing the message away would spare her the embarrassment.

    10. Re:why even ONE digit? by Anonymous Coward · · Score: 0

      Actually, I do send a date-timestamp from the script, but like to see how long it takes to get to my cell.

      And exactly what "purpose" is SMS "meant for" that precludes my "business-approved" purposes (by both IBM in the past, and the major pharma company employing me now - we all did/do it)? I have not seen such a definition from Verizon wireless...

      Time-date stamps are typical of all sorts of IT and human messages.

  17. Just shows... by Kupfernigk · · Score: 1
    The younger generation don't know what it was like coding for packed BCD. It's getting so bad I'm fixing an alarm to stop them getting onto my lawn in the first place.

    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.

    --
    From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
    1. Re:Just shows... by Nefarious+Wheel · · Score: 2, Funny
      Oooh you had LED displays? Sheer luuxury, mate. We used Nixie tubes and loved it. 256 bytes of memory? You gotta be jokin, mon. Who could afford that much memory?

      I don't think I have a lawn any more.

      --
      Do not mock my vision of impractical footwear
    2. Re:Just shows... by Anonymous Coward · · Score: 0

      No, you do. It's just shared by many others buried in the same cemetery as you.

  18. and they can bill you the future rate as well by Joe+The+Dragon · · Score: 2, 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.

  19. WHY DO PEOPLE INSIST UPON REPLACING THE FIRST ZERO by Anonymous Coward · · 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?

  20. Y2K vs. Y2K10 by phil42 · · Score: 0

    Are the negative effects of the Y2K10 bug worse than those of the Y2K bug ?

  21. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by Chabil+Ha' · · Score: 3, 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.

    --
    We're all hypocrites. We all have hidden parts, it's the contrast between them that make us more a hypocrite than others
  22. Re:Let me see if I can straighten it out, then. by clone53421 · · Score: 1

    WTF indeed... who were you replying to?

    --
    Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
  23. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by Anonymous Coward · · Score: 1, Informative

    Parent makes no sense.

  24. MESSAGE FROM THE FUTURE by ub3r+n3u7r4l1st · · Score: 2, Insightful

    This is an indication that the human race will survive 2012! Rejoice!

  25. Re:Let me see if I can straighten it out, then. by Rufty · · Score: 1

    MMXVI

    --
    Red to red, black to black. Switch it on, but stand well back.
  26. no that's a Y210 bug by rubycodez · · Score: 3, 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

    1. Re:no that's a Y210 bug by Dimitrii · · Score: 2, Insightful

      Mod points, I wish I had them.

    2. Re:no that's a Y210 bug by fnj · · Score: 1

      I know.

  27. This is a comment from 2016 by Anonymous Coward · · Score: 2, Funny

    Hi, guys!

    Due to a glitch in your space-time continuum, some of us have found ways to contact you. I just wanted to let you guys know that we are yet to invent flying cars.

    Please plan your expenses accordingly. That is all. Goodbye, past-commenters!

    1. Re:This is a comment from 2016 by mbkennel · · Score: 1

      By the way, President Palin declared past and present slashdot commenters to be enemy precombatants. SAIC has the contract for wifi in our Protective Custody Containment Areas and they're pretty good. The AT&T camps really suck, they make you buy only their own brain-dead card with no open source drivers.

  28. Wow it is 2016 already ... by Anonymous Coward · · Score: 0

    I can still recall in 2009 when they passed health care legislation, that would start after a long wait in 2014, but the time passed really quickly!

  29. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by rk87 · · Score: 1

    Y7E0

    --
    I'M NOT ANGRY!
  30. Uh, no. by msauve · · Score: 1

    As the OP pointed out, you're confusing the C literal expression with it's datatype.

    "0x" preceeding a C literal simply means that the literal is being expressed in hexadecimal. It tells the compiler how to interpret the literal, it doesn't type it. The type is given separately (e.g. "int 0x10" is the same as "int 16"). C doesn't provide binary literals, because it doesn't need to. Expressing as hexadecimal is more compact, and well understood (by most). One could equally well express that same literal as " '\020' " (which expresses a character of ordinal 10 decimal, and is expressed as an octal number), or by simply "10". They're all the same thing, the differences just make source code easier to read, they have nothing to do with how the data is actually used (encoded) by that code.

    But, it would have no doubt confused you even more if I had said that "16 is 10 decimal in BCD."

    The C literal "0x10" has the meaning "00010000" when interpreted in binary, 16 in decimal, 10 in BCD, and might mean "the clueful flags are off and the pedant flag is on" for a bit field.

    --
    "National Security is the chief cause of national insecurity." - Celine's First Law
    1. Re:Uh, no. by Jane+Q.+Public · · Score: 1

      No, I'm not confused. He is. And you misunderstood me.

      What we are talking about here IS the representation. I said nothing about type. In fact, type doesn't enter into it at all. "0x" stipulates that what follows is the hexadecimal representation of a number. This is not about internal hardware or memory storage... that would not make any sense, since to the best of my knowledge there is no machine in existence that internally stores numbers that include a "0x".

      GP stated that the representation of BCD and hexadecimal numbers in binary are the same... and that is simply not true. In 8 bits, the decimal number 96 is 01100000, but in BCD it is 10010110 (assuming normal bit order, no flipped nibbles). Those are two very different binary values, not the same at all.

      If you displayed those two values in a memory dump (as in the example he gives), expressed as hex or ASCII, they would look very different. The first one comes out as 0x60, the other as 0x96. That is the point I was making.

      It's just a communications issue, not one of confusion. Talking about two different things. What I was saying is that "0x" designates that the following number is represented in hexadecimal, nothing more. And in that context, it makes no sense to say "the BCD value 0x9234", because that is not a BCD value, it is a hex value. Regardless of the internal machine representation, which is a different matter entirely. In other words, what he stated is ambiguous. Did he mean the hex number 9234, as expressed in BCD? Or did he mean the BCD number 9234? They are not even close to the same.

    2. Re:Uh, no. by Jane+Q.+Public · · Score: 1

      To clarify a little bit maybe: he stated that 0x10 is 10 in BCD. But wait a minute... no it's not. 0x10, by definition, is a hexadecimal value. So expressed in BCD it would be 16. Therefore either his math is bad or he was using the "0x" designation for a BCD value... which is wrong.

    3. Re:Uh, no. by McGiraf · · Score: 1

      aaaaaaaaaaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrrrrrrrrrrrrrg!

      my head asplodes!!!!!!!!!!

    4. Re:Uh, no. by msauve · · Score: 1
      In C, "0x10" just represents a bit pattern. Sure, the "10" in that construct is in hex, but what "0x10" represents is simply a bit pattern, it's not hex, or decimal, or anything else until you apply some meaning to it. The exact same bit pattern can be represented by the literal "16".

      The bit pattern that it represents, if interpreted as BCD, is the decimal number 10, not 16.

      You seem very confused. One could take your statement

      0x10, by definition, is a hexadecimal value. So expressed in BCD it would be 16.

      and change it, by the same logic, to

      0x10, by definition, is a hexadecimal value. So expressed in decimal it would be 16.

      But, that completely ignores that BCD and binary encoding of decimal numbers is very different, and that's what the issue originally presented appears to revolve around.

      The pattern of bits represented by "0x10" is 10 if interpreted as the BCD representation of a decimal number and 16 if interpreted as the binary representation of a decimal number.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    5. Re:Uh, no. by clone53421 · · Score: 1

      Yes it is. The number 0x10 is merely a hexadecimal representation of a binary bit pattern that should be interpreted, if it is BCD, as 10 decimal.

      BCD packs one decimal digit into every binary nibble. Thus 37 decimal = 0011 0111 BCD, which is stored in memory as 00110111, and expressed in hexadecimal as 0x37. It is up to software to know that 0x37 = 37 decimal, not 55 decimal.

      The BCD number in hexadecimal is the same as the BCD number in decimal. Thus 0x15 = 0001 0101 = 15 decimal.

      If you were writing a C program and you wanted to use the number 52 as a BCD value, you would write it as 0x52.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    6. Re:Uh, no. by Whiteox · · Score: 1

      Don't worry, they're all wrong. They're too young to see that it's a hex base to decimal base conversion error and get confused with all this new fangled BCD and 0x stuff.

      It's pretty easy to work out that F=15 and the next number is 0A=16 so that's when in hex, it needs another byte.
      It's a units-tens-hundreds error from hex to decimal.

      So when the assembler coded 2009 and added 1 more to make it 2010, he/she did it in hex instead of decimal.
      Simple really.

      --
      Don't be apathetic. Procrastinate!
    7. Re:Uh, no. by clone53421 · · Score: 1

      Actually, you’re the one who’s wrong. The date is stored in BCD, according to the SMS standard.

      The correct way to count in BCD is 0x09, 0x10.
      The correct way to store those is 0x09, 0x10.
      The correct way to display them is 9, 10.

      And in this case, since they’re years, you add 2000.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    8. Re:Uh, no. by Whiteox · · Score: 1

      Doesn't matter how it's stored at all. It's a translation error from hexadecimal place value to decimal numeration, but we all know that.

      BCD follows assembly rules ('count' and a 'stack table' as you've pointed out) and is a characteristic and convention of the programming language. It may explain the mathematical error which is hex based:

      0 1 2 3 4 5 6 7 8 9 A B C D E F = MAX HEX UNITS USING A SINGLE NUMERICAL PLACE

      So the count goes to F which translates to 2009 due to programming logic applied,
      however on NEXT it goes to 10(HEX) - Look familiar? - as in 20(10) - 2010?
      So at the end of the programming loop (BCD or HEX) the COUNT variable contains 10(HEX)
      and the programmer sees this as 10 decimal instead of 10 hex.
      That's the bug.

      --
      Don't be apathetic. Procrastinate!
    9. Re:Uh, no. by clone53421 · · Score: 1

      No.

      The explanation is extremely simple. The year in an SMS message is stored in 2 BCD digits (1 byte).

      The correct way to store the number “10” in an SMS date would be the hex value 0x10. The problem was that they didn’t translate it back as a BCD value.

      So the count goes to F which translates to 2009 due to programming logic applied

      No... the year 2009 would be stored as 2 BCD digits: the value 0x09. (Not 0x0F.) In other words, the correct way to store the years 2007 2008 2009 2010 2011 in an SMS message would be, according to the SMS format,

      0x07 0x08 0x09 0x10 0x11

      Interpreted as BCD values, these dates are correct. The incorrect way to interpret these values would be to simply convert from hex to decimal (not their BCD values):

      7 8 9 16 17 (i.e. 2007 2008 2009 2016 2017)

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
  31. Oops. by msauve · · Score: 1

    " '\020' " (which expresses a character of ordinal 10 decimal, and is expressed as an octal number), or by simply "10".

    That should read:
    " '\020' " (which expresses a character of ordinal 16 decimal, in turn expressed as an octal number), or by simply "16".

    --
    "National Security is the chief cause of national insecurity." - Celine's First Law
  32. No. by msauve · · Score: 1

    0x10 is 16 decimal, when interpreted as the binary representation of a decimal number (i.e. an int).
    0x10 is 10 (hex) when interpreted as the binary representation of a hexadecimal number and is 10 (decimal) when interpreted as the binary representation of a BCD number. There is no "bcd/hex" mismatch in this case.

    It's a mismatch between BCD encoding and binary encoding.

    --
    "National Security is the chief cause of national insecurity." - Celine's First Law
    1. Re:No. by barv · · Score: 1

      The hex date has been translated twice to decimal. So .the date was (taking baseline as Y2K) Hex "A" which got translated to decimal "10" which was again translated to decimal (Hex "10" = dec "16") No binary except as incidental that 4 binary bits=1hex digit.

    2. Re:No. by msauve · · Score: 1

      Your desciption also explains why things worked just fine in 2009.

      So, the date was (taking baseline as Y2K) Hex "9" which got translated to decimal "9" which was again translated to decimal (Hex "9" = dec "15").

      Oh, wait. It doesn't.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    3. Re:No. by Jake+Griffin · · Score: 1

      Hex "9" = dec "15"

      Epic Fail. Hex "9" = 9 * 16^0 = 9 * 1 = 9 = Dec "9"

      --
      SIG FAULT: Post index out of bounds.
  33. The problem is due to by $0.02 · · Score: 1

    the Y2.01K bug

    --
    If enithin kan gow rong it whil. (Murfey)
  34. Comcast spammed my email with welcome to fancast by Anonymous Coward · · Score: 0

    On new years day Comcast spammed my email with "Welcome To Fancast" emails. I got at least ten of the same email.

  35. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by Unoriginal_Nickname · · Score: 1

    Which should be a hint about what's happening here.

  36. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by osu-neko · · 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.

    --
    "Convictions are more dangerous enemies of truth than lies."
  37. My bad. by Jane+Q.+Public · · Score: 1

    Let's try this again. The issue is getting confused. Or rather, it already was.

    0x10 (hex), in binary is 00010000. That same BINARY number expressed in BCD is 10. Okay so far. But the actual numeric value being represented is different: 16 and 10 (decimal).

    1. Re:My bad. by clone53421 · · Score: 1

      The 0x prefix does not mean that the number is or isn’t BCD. It means that it is a hexadecimal number, which it is.

      The same hex value, 0x10, is equal to either 10 or 16 depending on whether the stored number is in binary or a BCD number. That is what the OP originally said, and it is the simplest way to state it.

      If you want to store the number 10 in BCD, the contents of your memory location will be 0x10.

      If you want to store the number 16 in binary, the contents of your memory location will also be 0x10.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    2. Re:My bad. by Jane+Q.+Public · · Score: 1

      Incorrect. That is, I understand perfectly what you are saying (I stated the same things above, if you want to go back and read what others have stated before), but that was not the point.

      First, "OP" didn't say anything about it at all. This was in response to GP ("Mr. Z").

      Second, did you even read my other comments? I am referring to VISUAL REPRESENTATION here, NOT how the number is stored. "0x" designates a number being represented, or displayed, as a hex value. It is not being displayed as a BCD value. This has nothing to do with how it is being treated internally by the machine.

      I stated that quite explicitly. Maybe you would care to go back and read the rest of the thread before throwing in your 2 cents?

      And just for the record, GP's statement that the visual representation (as in "0x222") and "encoding" are different is simply false. They are simply 2 different ways to represent a number. Machines are capable of storing a number as BCD or a binary representation of decimal or hexadecimal... they are all "encoded" in that sense, making any distinction between "representation" and "encoding" absolutely meaningless. As I mentioned before, if he were talking about internal machine representation or storage, he should say so... but that is not what he stated and that is a different matter.

    3. Re:My bad. by clone53421 · · Score: 1

      "0x" designates a number being represented, or displayed, as a hex value. It is not being displayed as a BCD value. This has nothing to do with how it is being treated internally by the machine.

      This is just plain wrong. If you want to go find some sources to back up this claim, feel free to try, but until then please stop repeating it.

      BCD values are normally given as hex values (i.e. the value actually stored in memory). The number 12, in BCD, is 0x12, 00010010, or 18. It would be stupid to write it in decimal, because it would only confuse people. However, the value being stored would never be written as “12”, unless it was implicit that you were writing it in hex (e.g. in certain variants of assembly language all constants are written in hex by default).

      The 0x notation is commonly used when writing hex values, including when writing BCD hex values. As I have said elsewhere, if you are storing a BCD number in a C program for an embedded project, you’ll use hex 0x notation. There is no other sensible way to store the value.

      I actually took embedded design courses in college and we did BCD operations on embedded microcontrollers, by the way. I think I know what I’m talking about. But don’t just take my word for it... /t21476-re-binary-to-bcd-assistance.html#post132747 involves exactly this scenario: working with binary and BCD numbers (more specifically, converting from one to the other). Binary and BCD are encoding formats, not to be confused with the representation (hex) or the internal storage (binary). As you can clearly see, BCD values are given in hex 0x notation:

      carry = (bcd[j] & 0x10) == 0x10;

      ...

      printf(" %x\n", bin);

      Note that the correct printf format for a BCD number is %x. BCD numbers are written in hex. Do this:

      #include <stdio.h>

      int main() {
          unsigned long num;

          num = ???;
          printf("%x", num);

          return 0;
      }

      What are you going to put in the place of the “???” to get it to print “12”? You will use “0x12”, of course. Anything else would be silly.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    4. Re:My bad. by Jane+Q.+Public · · Score: 1

      "As I have said elsewhere, if you are storing a BCD number in a C program for an embedded project, you'll use hex 0x notation."

      And as I have stated repeatedly, I was NOT referring to storage at all! I am referring to visual representation only! Storage is a completely different matter from what I have been discussing. Get a damned clue. If you want to try to contradict me, you could at least stick to the same subject.

      "The number 12, in BCD, is 0x12, 00010010, or 18. It would be stupid to write it in decimal, because it would only confuse people. However, the value being stored would never be written as "12", unless it was implicit that you were writing it in hex (e.g. in certain variants of assembly language all constants are written in hex by default)."

      And there you go yet again, mixing the machine representation of the number with the value as displayed on the screen. One more time: this was not about internal storage!

      And in fact you proved my point for me: "The number 12, in BCD, is 0x12, 00010010, or 18." This is exactly what I was saying. Here are 3 different representations of the same numeric value, and each one looks different! The digits on the screen that represent numbers are different, depending on whether the number is displayed as hexadecimal, binary, BCD, or decimal! Is that so hard to understand?

      And my last point was that if, for example, you were doing some math, unless you do some explicit conversion your compiler will interpret 0x12 as being equivalent to the decimal number 18, not the BCD value represented by those digits, which would be decimal 12. You state this yourself: "However, the value being stored would never be written as "12", unless it was implicit that you were writing it in hex..."

      So, despite your apparent misunderstanding of what I wrote earlier, what you wrote here actually agrees with me. Except for one small item, if you really want to get into storage:

      "Binary and BCD are encoding formats, not to be confused with the representation (hex) or the internal storage (binary)."

      First, this sentence contradicts itself: "Binary and BCD are encoding formats, not to be confused with ... the internal storage (binary)." But aside from that, this is an artificial distinction. All 3 (binary, BCD, hexadecimal) and more if we want to include decimal, octal, and so forth, are simply different ways to represent numbers. There is no difference between "encoding format" and "visual representation" of a number. I could write a program to display a number in any of those formats if I wish. So they can all be dealt with natively, using the right software, and theoretically there is nothing keeping us from constructing hardware that represents numbers internally in any of those formats as well. The only reason our machines use binary (or octal, or BCD), is because it is easier today to make the hardware operate in binary. But that is just a convenience. "Encoding format" is not anything special. What is silly is trying to put a number representation scheme in a special category, simply because some machines (not all) use it internally. When I worked with a PDP-11, I had to deal with numbers in software that were represented in octal, which was also what the machine used internally. Same for BCD regarding certain old IBM machines. So, as I mentioned: octal, BCD, binary, decimal are simply ways to represent a number, no more, no less. There is no real difference between your "encoding", and any other numeric representation.

    5. Re:My bad. by clone53421 · · Score: 1

      Storage is a completely different matter from what I have been discussing. ... One more time: this was not about internal storage!

      YES IT WAS.

      The SMS format states that the year is stored as a 2 digit BCD number, e.g. 0x10. How it is displayed, obviously, is as 2010. This is totally about how it was stored, and how to convert that back into printable form. It was stored as 0x10, according to the SMS standard. That should have been interpreted to mean 2010, not 2016.

      unless you do some explicit conversion your compiler will interpret 0x12 as being equivalent to the decimal number 18, not the BCD value represented by those digits, which would be decimal 12.

      Yes, your compiler WILL interpret 0x12 as being equivalent to the decimal number 18, and as it should. Your math routines and display routines must correctly interpret the BCD number as a BCD number, not an integer stored in 2’s complement form.

      First, this sentence contradicts itself: "Binary and BCD are encoding formats, not to be confused with ... the internal storage (binary)."

      No. You completely missed the point I was trying to make. Binary is both an encoding format and a number storage format, and these are distinct, not to be confused with each other.

      A “binary” integer is a signed or unsigned number encoded in 2’s complement form. If you want to be picky, 2’s complement is really the encoding format you’re using, but that is often referred to as a “binary” number (because 2’s complement is how most integers are stored in binary).

      Now, if you want to be really anal and claim that msauve was incorrect, then his statement should have been phrased as such:

      0x09 = 9 decimal when interpreted as either 2’s complement or BCD.

      0x10 = 10 decimal when interpreted as BCD, as 16 when interpreted as a 2’s complement integer.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    6. Re:My bad. by Jane+Q.+Public · · Score: 1

      "YES IT WAS."

      Don't try to tell me what I was discussing. That's idiotic. YOU might have been writing about SMS using a BCD representation of the number, but I was not. I clearly stated -- 3 times no less -- that I was discussing something else: certain statements made by GP, not OP's post at all. So you were reading my post in light of a context that didn't really exist... you just assumed it. Are you still unclear on this? Do you need me to repeat it yet again?

      "Yes, your compiler WILL interpret 0x12 as being equivalent to the decimal number 18, and as it should. Your math routines and display routines must correctly interpret the BCD number as a BCD number, not an integer stored in 2's complement form."

      Can you say "Duh"?? That is what I stated, twice now. Except for the 2's complement part, which is irrelevant to the discussion.

      "No. You completely missed the point I was trying to make. Binary is both an encoding format and a number storage format, and these are distinct, not to be confused with each other."

      I didn't MISS anything, because that's not what you wrote. Go look again. You wrote ""Binary ... not to be confused with ... the internal storage (binary)."" Sorry, but you contradicted yourself. If that is not what you meant, then you should have written it differently. Don't blame me. Further, it is not I who missed the point here. You appear to be claiming that "encoding" is not "a way to represent a number", as I wrote... and that is just plain wrong. It doesn't matter whether it is software or hardware, it is nothing more than a way to represent a number. And further yet, even if this were not an arbitrary and artificial distinction, it is also irrelevant, because YET AGAIN, I was not discussing machine storage. You were. The ONLY time I discussed the subject at all (other than having previously mentioned, repeatedly, that it was NOT the topic of discussion), was in answer to your comment.

      "A "binary" integer is a signed or unsigned number encoded in 2's complement form..."

      Talk about assumptions! Not only are you back to hardware again, you have assumed that the hardware being discussed is an Intel or other processor that does indeed represent numbers internally as the 2s complement of a binary integer. But as a general answer this is still wrong. A binary integer is merely a collection of 1s and 0s, straightforwardly representing a number in the binary numbering system. The 2s complement of a binary integer is itself a binary integer... but a different one. In fact, I have already mentioned the old PDP-11, which represents numbers internally in octal... which looks neither like the "original" binary integer, or its 2s complement. All of which is completely outside the scope of what I was originally stating.

      It is you who missed that point. While I am loathe to be discussing hardware at all here (because that is not what I was originally writing about, for about the 7th time now), I repeat that your "encoding" is nothing more than another way to represent a number. Denying that is just silly.

      "Now, if you want to be really anal and claim that msauve was incorrect, then his statement should have been phrased as such:"

      Let's try it again, shall we? First, to be clear, 2's complement HAS NOTHING TO DO WITH IT. I am referring here only to the numbers as represented right there on the page, not anything to do with hardware or internal representation!

      So, using the common standard "0x" form to denote hexadecimal, we have (assuming this is 8-bit, and we are not using "packed" BCD and leaving 2's complement the hell out because it's irrelevant):

      0x9 (hexadecimal) = 9 (decimal) = 00001001 (binary) = 0000 1001 (BCD)

      0x10 (hexadecimal) = 16 (decimal) = 00010000 (binary) = 0001 0110 (BCD)

      0x12 (hexadecimal) = 18 (decimal) = 00010010 (binary) = 0

    7. Re:My bad. by clone53421 · · Score: 1

      I clearly stated -- 3 times no less -- that I was discussing something else: certain statements made by GP, not OP's post at all. So you were reading my post in light of a context that didn't really exist... you just assumed it. Are you still unclear on this? Do you need me to repeat it yet again?

      YOU originally responded to ME, and I think it’s legitimate for ME to tell YOU what WE are talking about, since YOU obviously missed it somewhere along the way.

      (Go back and look at the comment history. You seem extremely confused. For instance, this from your previous post: “First, "OP" didn't say anything about it at all. This was in response to GP ("Mr. Z").” — but there is no “Mr. Z” anywhere above that post in the comment tree. Check if you don’t believe me.)

      Not only are you back to hardware again, you have assumed that the hardware being discussed is an Intel or other processor that does indeed represent numbers internally as the 2s complement of a binary integer.

      Good heavens, are you really this pedantic? Maybe that’s the entire problem. Yes, I’m assuming those things, because the assumptions are correct in this particular situation!

      THE PROBLEM WAS SIMPLE.

      They took an 8-bit packed BCD value – 0001 0000, 0x10, 16, or whatever else you want to represent it as – and they treated it as if it was an 8-bit 2’s complement integer. If you store the number 10 as a packed BCD number, then read it as a 2’s complement number, you get 16.

      Is that then perfectly clear and stated to an acceptable level of accuracy?

      So, using the common standard "0x" form to denote hexadecimal, we have (assuming this is 8-bit, and we are not using "packed" BCD and leaving 2's complement the hell out because it's irrelevant):

      We are using packed BCD (and you apparently don’t know what that means because then you did use it after saying you weren’t).

      Unpacked BCD uses 8 bits per digit. The number 24 in unpacked BCD is 00000010 00000100 (0x0204). This is convenient because ORing an 8-bit unpacked BCD digit with the 8-bit ASCII character ‘0’ (0x30) converts it to the corresponding ASCII digit (ASCII characters 0-9).

      Packed BCD uses 4 bits per digit. The number 24 in packed BCD is 0010 0100 (0x24). This requires half the space of unpacked BCD, but it’s not as convenient to convert a 4-bit packed BCD digit to an 8-bit ASCII character. (You have to first “unpack” each byte.)

      0x24 (hexadecimal) = 36 (decimal) = 00100100 (binary) = 0011 0110 (BCD)

      You forgot one. The one that is the MOST COMMON WAY OF REPRESENTING A BCD NUMBER, aside from perhaps decimal:

      0x24 (hexadecimal) = 36 (decimal) = 00100100 (binary) = 0011 0110 (BCD) = 0x36 (BCD)

      Note the “36 (decimal) = 0x36 (BCD)”. THAT IS THE WHOLE ADVANTAGE OF BCD.

      0x10 is not "16 in the binary encoding system".

      “0x10 is 16 in the 2’s complement encoding system,” then.

      Commonly referred to as a “binary integer”.

      Thus the horrible mistake that msauve seems to have made: using the word “binary” when he meant “2’s complement integer”.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    8. Re:My bad. by Jane+Q.+Public · · Score: 1

      "YOU originally responded to ME, and I think it's legitimate for ME to tell YOU what WE are talking about, since YOU obviously missed it somewhere along the way."

      That's pretty funny. Yes, it was you, but no, it is still not legitimate for you to assume you know what I was trying to say, when obviously you don't. You are saying that it is legitimate for you to try to read my mind, and tell me what I meant? I don't think so.

      It is true that previously I had stated that I replied to Mr. Z... and I don't know why. No doubt about it, that was my mistake. I don't mind admitting mistakes when I actually make them.

      "They took an 8-bit packed BCD value - 0001 0000, 0x10, 16, or whatever else you want to represent it as - and they treated it as if it was an 8-bit 2's complement integer. If you store the number 10 as a packed BCD number, then read it as a 2's complement number, you get 16."

      That is what YOU were writing about. But that is NOT what I was writing about... for roughly the 8th time now. Why do you have such trouble understanding that concept??? What I was writing about was your confusing way of trying to explain it.

      And further, your statement that I was using packed BCD is incorrect. The numbers I showed were in plain, unmodified, unsigned BCD. Your BCD above is fine if you are referring to simple unsigned BCD, but packed BCD uses the lowest nibble to indicate sign, not to contain a number value. If you don't believe me, read about it here, and see just above that, in the same article, for unpacked BCD. A regular (unpacked) BCD digit is typically represented in either 4 or 8 bits. For many years 4 bits was the common standard for an unsigned, unpacked, BCD digit.

      Your statement that packed BCD uses 4 bits and unpacked BCD uses 8 bits is just plain wrong. A standard BCD digit can be 4 bits, while a packed BCD digit needs at least 8 bits... it can actually be any multiple of the word size. I seldom use Wikipedia as a citation but their explanation of this is as good as any. Further, a packed BCD number is not necessarily smaller than a non-packed BCD number: take decimal 90 for example. In straight unsigned BCD that can be represented by 1001 0000. But in packed BCD you need 2 bytes: 00001001 00001010, where the last 4 bits represent the sign.

      "Unpacked BCD uses 8 bits per digit. The number 24 in unpacked BCD is 00000010 00000100 (0x0204)."

      You keep taking these specific cases and writing about them as though they are hard-and-fast rules, but that is simply not so... again, as Wikipedia clearly explains in that article. And even if your machine used 8-bit representation of UNpacked BCD, even that is still an erroneous generalization. On a standard machine that represented text as 8-bit ASCII, the first nibble of each byte would be 0011, not 0000, so 24 in BCD would be 00110010 00110100. Admittedly, that would be an older machine... but after all we have been using 8 bits. My point being that not all implementations of BCD are the same.

      "0x24 (hexadecimal) = 36 (decimal) = 00100100 (binary) = 0011 0110 (BCD) = 0x36 (BCD)"

      And THAT was precisely my point. Unless you are doing explicit conversion, 0x24 (which SPECIFICALLY denotes hexadecimal in most languages), will be interpreted as being equal to 36 decimal. On that part we are agreed. But here is what I was talking about: if you input 0x36 into a C program or most other languages that support that number format, and do not do any explicit conversion, that number will be interpreted as 54 decimal, NOT as 0011 0110 (BCD) or 36 decimal. That was my point. You might prefer to write that BCD number as 0x36, but that is not how a compiler will interpret it. And for that matter, unless you explicitly label that in code as some kind of BCD representation, any programmer to come along later will also assume it i

    9. Re:My bad. by clone53421 · · Score: 1

      Yes, it was you, but no, it is still not legitimate for you to assume you know what I was trying to say, when obviously you don't. You are saying that it is legitimate for you to try to read my mind, and tell me what I meant? I don't think so.

      I’m actually quite confused as to what you’re trying to say, so I’m falling back to explaining what I was saying, under the assumption that you misunderstood me, or don’t understand BCD, or both.

      Your BCD above is fine if you are referring to simple unsigned BCD, but packed BCD uses the lowest nibble to indicate sign, not to contain a number value. If you don't believe me, read about it here

      That entire section is in severe need of a [Citation needed]. Everything I did in college with BCD referred to “packed” BCD as 2 digits per byte with no sign nibble of any sort, and “unpacked” BCD as 1 digit per byte.

      If you want to allow for signed packed BCD, fine, but don’t tell me that my unsigned form of packed BCD isn’t packed BCD! Look at any of the google results other than that one Wikipedia article:

      Here, here, here, here (pdf), here.

      This gem is even entitled “Packed BCD to 16 bit binary conversion”... when of course I’m sure they meant “2’s complement”, not “binary”, since that was the whole problem from the beginning of this discussion! You should e-mail them and tell them to fix it!

      What I was writing about was your confusing way of trying to explain it.

      You seem to be one of a very small group of people who thought it was confusing. Is that my fault?

      But here is what I was talking about: if you input 0x36 into a C program or most other languages that support that number format, and do not do any explicit conversion, that number will be interpreted as 54 decimal, NOT as 0011 0110 (BCD) or 36 decimal. That was my point. You might prefer to write that BCD number as 0x36, but that is not how a compiler will interpret it.

      The compiler doesn’t “interpret” anything. The programmer does. The compiler just creates a binary executable that does whatever the programmer designed it to do.

      And for that matter, unless you explicitly label that in code as some kind of BCD representation, any programmer to come along later will also assume it is hexadecimal. So you are introducing confusion into the issue.

      Yes, which is why we have standards to tell programmers how stuff is supposed to be written.

      0x10 is a HEXADECIMAL representation of the decimal number 16.

      It is also a BCD representation of the decimal number 36.

      I have nothing more to say to you. I have explained this more than once and in about 3 different ways. As Wikipedia (and other sources if you would care to look them up) clearly show, you have been wrong about some of these things. If you still don't understand the rest, I don't feel like spending more time to help you.

      And the Wikipedia warrior throws up his hands!

      I, on the other hand, didn’t learn everything I know from Wikipedia.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    10. Re:My bad. by Jane+Q.+Public · · Score: 1

      "If you want to allow for signed packed BCD, fine, but don't tell me that my unsigned form of packed BCD isn't packed BCD! Look at any of the google results [google.com] other than that one Wikipedia article:"

      I did look at the google results you listed, as well as some others that supported my position. From what I could see, there are approximately the same number of each, depending on exactly how you do the query.

      I looking into this further, and discovered that actually we were both right to some degree, and both wrong to some degree. At least in modern terminology.

      BCD was used with 4-bit processors, back when they were hot stuff (which you may be too young to remember), generally representing just positive integers. Later, when 8-bit processors came around, putting 2 digits into 8 bits was the natural thing to do (storage was very expensive in those days). One did not waste one's storage space (or double the number of processor cycles for a some operations) by leaving half a word blank... it just wasn't done. So what you call "packed" BCD -- for unsigned integers -- is what was then just called plain ol' BCD.

      It was when people started thinking seriously about representing signed numbers in BCD that the format as shown on that Wikipedia page was drummed up. It's still basically the same, except that the 4 least significant bits are used to represent the sign.

      And it was only later, when processors were faster and storage cheaper, that single BCD digits started to be stored in 8-bit bytes.

      So... your "packed" BCD and my "normal" BCD are basically the same, for unsigned integers. It is the signed numbers that use the other format. But keep in mind that signed BCD numbers are not limited to 8 bits... according to the specification, they can be any arbitrary multiple of the word size. That is why BCD is still used in arbitrary-precision calculations... one of the few places that it is still used widely.

      I guess the lesson there is to not be a "bit-size" bigot, because we were each stuck on our own fixed-width interpretation of BCD.

      But here is where we definitely part company, because you obviously did not understand what I was saying, no matter how I stated it or how many times:

      "The compiler doesn't "interpret" anything. The programmer does. The compiler just creates a binary executable that does whatever the programmer designed it to do."

      That is actually pretty funny. I don't want to get into specific languages here, so I will try to be as generic as I can, but are you trying to tell me that, for example, your compiler does not interpret the sequence "if a==b" as the start of a conditional block of code, and so convert it to the beginning of a machine-readable conditional block of code? I have to disagree with you. Almost all a compiler does is interpret your person-readable code and convert it to machine-readable code. I don't for the life of me see why you have a problem with the word "interpret" there... because indeed, the compiler is simply interpreting from one "language" to another. Just as a human interpreter would do.

      "You seem to be one of a very small group of people who thought it was confusing. Is that my fault?"

      Yes. Most people probably did not even bother to read the part I took exception with, and of those few who did, I doubt very many felt motivated to call you out on it.

      "Yes, which is why we have standards to tell programmers how stuff is supposed to be written."

      And yet again, you bring up the SMS issue, after I have already stated 10 times that my comment was not about that, but rather about YOUR WRITING. Why do you persist in this? Is your name Don Quixote?

      "It is also a BCD representation of the decimal number 36."

      No, it's not. Even given my statement above that we were both about equal

    11. Re:My bad. by clone53421 · · Score: 1

      are you trying to tell me that, for example, your compiler does not interpret the sequence "if a==b" as the start of a conditional block of code, and so convert it to the beginning of a machine-readable conditional block of code?

      Not in the least. The compiler interprets the literal function of the code: the start of a conditional block of code. What I was trying to point out is that the compiler does not interpret the meaning of that code. It doesn’t care. It only cares about what the code does. That’s why you can write a program that takes a BCD number and converts it to decimal incorrectly, like they did in this situation. The compiler neither knows nor cares that the number is BCD. It just does what you tell it to.

      Maybe I was reacting to something you weren’t really saying. There is only one correct way for the compiler to interpret 0x36. Whether I mean 54 decimal or 36 decimal by it – well, the compiler neither knows nor cares which it is. It interprets the characters I typed, sure, but it doesn’t interpret the meaning of the number it’s storing.

      And even if you were correct in saying it was BCD (you are not), it would be a representation of decimal 10, not 36.

      Well, that’s embarrassing. Yes, I meant 10. Not sure where 36 came from.

      0x10 is a BCD representation of the decimal number 10. To the computer, it’s just a bit pattern stored in a memory cell, represented in hexadecimal. To the programmer, however, it’s a BCD number. What’s wrong with saying this?

      Again, if I want to store the number 10 as a BCD number, I enter:
      a = 0x10; – because 0x10 is the hexadecimal BCD representation of 10.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    12. Re:My bad. by Jane+Q.+Public · · Score: 1

      "Not in the least. The compiler interprets the literal function of the code: the start of a conditional block of code"

      See, this is why I am done arguing with you. You just contradicted yourself again. Earlier you stated (in exactly the same context): "The compiler doesn't 'interpret' anything. The programmer does."

      You seem to feel free to change your argument depending on convenience.

    13. Re:My bad. by clone53421 · · Score: 1

      Maybe I was reacting to something you weren’t really saying. There is only one correct way for the compiler to interpret 0x36. Whether I mean 54 decimal or 36 decimal by it – well, the compiler neither knows nor cares which it is. It interprets the characters I typed, sure, but it doesn’t interpret the meaning of the number it’s storing.

      That was my whole point.

      Interpret is really the wrong word to use. The word that fits is “translate”. To interpret something means to explain it (an interpreter doesn’t do a word-for-word translation, like an online translator would... the interpreter also has to express slang, figures of speech, and other literary oddities in the native tongue of the audience and in a way they will understand).

      Merely translating something, however, does not require any knowledge of what you are translating, only a set of rules to convert from one to the other. When I said the compiler doesn’t “interpret” anything, this is what I meant. It translates, it doesn’t interpret. Even when it optimizes, it doesn’t interpret the meaning... the output machine code must still do exactly what the input source code said to do.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
  38. Fuktion by Tablizer · · Score: 1

    What function could cause this kind of error?

    Something like "fuckUpIn2010(time);" I would recon.
       

  39. It's log it's log! by Anonymous Coward · · Score: 0

    What rolls down stairs
    alone or in pairs,
    and over your neighbor's dog?
    What's great for a snack,
    And fits on your back?
    It's log, log, log

    It's log, it's log,
    It's big, it's heavy, it's wood.
    It's log, it's log, it's better than bad, it's good."

    Everyone wants a log
    You're gonna love it, log
    Come on and get your log
    Everyone needs a log
    log log log

    -- Ren and Stimpy

  40. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by Anonymous Coward · · Score: 0

    It doesn't take away from the fact that 2k16 is dumb as hell.

  41. solution by Anonymous Coward · · Score: 0

    Yeah... they need to fix it so that this year's SMS messages are stored with a year of 0x000A instead of 0x0010. Then, there will be no more messages from 6 years in the future. And, next year better be 0x000B. The routine being used is converting decimal to hex such that the two nybbles represent the decimal digits. Hex is better anyway, one byte can store 2000 to 2255 that way (instead of 2000 to 2099).

    1. Re:solution by clone53421 · · Score: 1

      No... they just need to fix the software. The year in an SMS message is stored in an 8-bit packed BCD value. They decoded it incorrectly.

      In other words, they don’t need to change 0x10 to 0x0A. They need to make their software decode 0x10 as the year 2010.

      Yes, hex would be able to store a wider range of values than BCD, but who needs to keep an SMS message for longer than 100 years? In the rare case that you do, store it in some external data package that can hold 4-digit years.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
  42. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by shentino · · Score: 1

    More like an attempt to capitalize on Y2K's notoriety by partially mimicking it.

    Or...just be glad nobody's trademarked Y2K.

  43. here it goes again by dandu · · Score: 1

    anyone remember the zune mass suicide? http://it.slashdot.org/article.pl?sid=08/12/31/1428254

    billy really needs to get back to basics

  44. Its the LHC effect again! by Anonymous Coward · · Score: 0

    Another example of nature preventing us from discovering the Higgs and annihilating ourselves.
    The Large Hadron Collider was calibrated late 2009 and began doing physics in early 2010. The Higgs was discovered in 2011 and promptly engulfed us all, absorbing all parallel universes up to about 2015 (our timescale) through entanglement of the Class I strings. Only 2016 onwards is defined.
    Google Drs Holger Bech Nielsen and Masao Ninomiya and read all about it!

  45. To summarize slashdot, they were Hexed! by argent · · Score: 1

    So, basically, this was a simple case of code misconverting from BCD to binary, interpreting 4-bit nybbles representing 1 ten and zero ones as 1 sixteen and zero ones. Or, to summarize the summary, they were hexed.

  46. What function could cause this kind of error? by LuniticusTheSane · · Score: 1

    Time travel.

  47. I can confirm this by BurfCurse · · Score: 1

    I have an HTC Touch Diamond. All text messages I've received since the new year are showing from 2016.

  48. instead of y2k16... by Anonymous Coward · · Score: 0

    shouldn't this be called y2kxf?

  49. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by RockDoctor · · Score: 1

    Those COBOL programmers would be rolling in their graves.

    They would be ... if they were dead. Or undead, by day. Or just had particularly odd sleeping habits.
    There are probably still a lot of people maintaining, and possibly even coding from new in COBOL.

    I read on Wikipedia that: "The COBOL 2002 standard includes support for object-oriented programming and other modern language features."

    I shudder. That sounds truly horrible. Can I have Object-Oriented Intercal for next Christmas?

    --
    Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
  50. What about testing? by Anonymous Coward · · Score: 0

    Surely the testing strategy should be brought into question? Would seem sensible to test various dates in a currency-handling system. However, having worked for a short while as a tester for an EFT/POS company, I can fully understand. Though not the main reason for leaving, the quality of engineering practices and principles was very poor.

  51. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by Heian-794 · · Score: 1

    This time it isn't bytes, but pronunciation.

    "Two thousand sixteen", the most natural way to say the number, uses three syllables for the "20.." part.

    How can we make that shorter and easier to say? Using "twenty..." sounds a bit silly as it doesn't flow well and there's no "twenty hundred" to abbreviate from. The retro hipster in me wants to see something with "two ought" in it, but let's face it, the "2k" thing saves a syllable and is already popular, and has a futuristic, metric/computer feel to it. It's perfect.

    (Now can we get started on actually bringing 2k10 into the "metric age"? It was disappointing to pick up Clarke's classic on the first day of 2010 and see him make a wrong prediction in the first sentence!)

  52. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by Jake+Griffin · · Score: 1

    If by "twenty hundred" you were referring to 2100, I would think that "twenty-one hundred" would be fine for that, and "twenty-one forty-six" for 2146, etc. "two kay one-forty-six" is a lot more confusing IMHO...

    --
    SIG FAULT: Post index out of bounds.
  53. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by Heian-794 · · Score: 1

    "Twenty-one hundred" for 2100 is just fine, as is "twenty-one forty-six" (because you're just omitting the word "hundred"). The "k" stuff only works until 2099, when it stops being an advantage. Then we go back to what we did in the nineteen-hundreds, which is to take out the word "hundred". In the current century, there's no word "hundred" that needs to be abbreviated.

  54. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by Trogre · · Score: 1

    To make matters worse, strictly speaking Y2K16 evaluates to 2160 (think of a 4K7 resistor). It would be more accurate to say Y2K016, in which case the 'K' is completely redundant.

    --
    "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
  55. Symantec scores an own-goal by LostCluster · · Score: 1

    Docken may have just gotten to the chicken... Symantec effectively D-DOSed their update servers with code that made practically every one of their own customers think they hadn't updated recently enough and query to see if there was anything new. Nice work guys...

  56. Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z by bdg2 · · Score: 1

    As an EE I'd like to say that yes I am smart enough to know what was meant when people WRONGLY referred to 2016 as 2K16.

  57. The workaround for this HAS BEEN STOLEN by bdg2 · · Score: 1

    Some slimy git on the Sprint BBS is pretending to be ziggy471 that creating the original workaround for this Wm bug and released it here:
    http://forum.ppcgeeks.com/showthread.php?t=104248
    as "Ziggy 2016 fix.cab"
    The main thread in the sprint BBS is this:
    http://community.sprint.com/baw/thread/25879
    The impersonator is calling himself Ziggy on the Sprint BBS.
    He has changed the file name to "Ziggy 2016 fix final.cab" and is spouting some rubbish about the final version having been fixed so that the problem will not happen again on various other dates in 2010 and 2011!!
    HE IS ASKING FOR DONATIONS!!
    The real ziggy471 went on the BBS and pointed out that it was his work and he did not want donations but the idiots at Sprint appear to believe the impersonator and have locked the thread and deleted all the messages from the real ziggy471.
    I am disgusted.

  58. Not a fix by Anonymous Coward · · Score: 0

    This is not a fix. It merely substitutes an incorrect date (the time/date the message was received) for another incorrect date. When I turn on my WM 6.1 phone, it takes anywhere from 5 minutes to 4 hours to receive text messages, the timestamp inder the “fix” would be off considerably.

    1. Re:Not a fix by bdg2 · · Score: 1

      This is not a fix...

      Don't tell me, I never said it was a fix.
      However It does seem to be a useful workaround for many people, especially for people who like to view their texts in threaded mode.