Slashdot Mirror

← Back to Stories (view on slashdot.org)

Epoch Time Bug Causes Facebook To Congratulate Users On 46 Years of Friendship (gizmodo.com)

Posted by Soulskill on from the somebody-missed-an-edge-case dept.

An anonymous reader writes: A bunch of Facebook users received mysterious messages yesterday congratulating them on 46 years of being friends with somebody on Facebook. An astute observer may note that Facebook hasn't been around for 46 years. An even more astute observer might note that 46 years ago yesterday would be 12/31/1969 — easily recognizable as value '0' in the Unix Epoch with a time zone adjustment. A Microsoft engineer posits that the messages were sent because of how Facebook implemented its congratulatory messages. Many people were Facebook friends when the feature was rolled out, and instead of finding or estimating the date they became friends, Facebook simply set that database value to '0'. When the script fired to send those messages, it grabbed that value expecting a time, and interpreted the 0 accordingly. "The developer who wrote the "friends with since" memories algorithm should have added a case WHERE friendsWithSinceDate != '0' or something along those lines."

12 of 108 comments (clear)

  1. Oblig by American+AC+in+Paris · · Score: 5, Funny

    Epoch fail.

    --

    Obliteracy: Words with explosions

    1. Re:Oblig by Hognoxious · · Score: 2

      At least facebook's logon system works.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    2. Re:Oblig by Anonymous Coward · · Score: 4, Funny

      and you see that as a good thing?

  2. Not an Epoch bug by Predius · · Score: 4, Insightful

    It's not an Epoch time bug, it's a lazy programmer bug. If you're going to use X time system, do so intelligently. If you're going to use Y time system... etc.

    1. Re:Not an Epoch bug by QuietLagoon · · Score: 2

      It's not an Epoch time bug, it's a lazy programmer bug....

      Exactly correct. At least the Microsoft Engineer put the blame in the correct place when he wrote, "The developer who wrote the 'friends with since' memories algorithm should have ..."

    2. Re:Not an Epoch bug by WorBlux · · Score: 2

      Or strenthen your type system. If you mean false, don't write a zero literal into your code.

    3. Re:Not an Epoch bug by Darinbob · · Score: 2

      But 0 is a real and valid time. It's a common issue when people borrow time systems without understanding them. Unix time was invented to specify file dates only. But it got repurposed to do stuff which it was not designed for. Ie, you can not specify necessary medical information dates using 32 bit Unix time. People keep reusing Unix time because they don't know how to do a different time library. Expanding to 64 bits is ok, but keeping 1/1/1970 as the epoch is a bit strange (pick maybe year 0, or 2000). And eventually people need time measurement of less than a second and I see a great many systems that can't keep sub-second timing in sync with their Unix seconds-since time..

      And I don't think the test versus 0 is very good in this case. There are indeed people who met and became friends on 1/1/1970. If using 64 bit times then pick a date in the extreme past, or if on 32-bit time then 0xffffffff will minimize (but not entirely eliminate) conflicts. Better yet have a system of "friends since" that uses only calendar days but not times within a particular day.

      Times and dates are hard things, which is why people want to use libraries. However the current fashion of never writing new code and only using libraries should always be used along with the caveat to fully understand the libraries before you use them. (ain't no one got time for that we've got to ship by Friday)

  3. NULL is there. Use it! by DahGhostfacedFiddlah · · Score: 3, Interesting

    I don't understand people who prefer to use magic numbers over NULL, but there appear to be many.

    --
    Last post!
  4. Re:NULL is there. Use it! by Anonymous Coward · · Score: 2, Interesting

    NULL is a special case in any SQL database. If you try to check if something is equal to NULL, you will always receive false. Even NULL = NULL is false. That forces you to specifically check for a NULL value using IS NULL instead of accidentally bumping into correct functionality, but having things inexplicably break later on.

    And the fact is, this Facebook bug is probably caused by how most data connector libraries interpret a NULL timestamp in MySQL (IIRC, FB uses a heavily-modified variant of MySQL). They're technically NULL, but the connector libraries always return it as 1969-12-31 00:00:00.000. (Which is retarded, because the time component is all sorts of stupid and broken in that value. If they were going to make it one-step-before-zero, it would have a time of 11:59:59.999. And also because NULL should be NULL, not a value that might be valid to other types of code.)

  5. Re:NULL is there. Use it! by known_coward_69 · · Score: 2

    NULL has it's own set of issues like you can't index it because it's not zero, it's not nothing or blank, it's literally unknown

  6. Re: NULL is there. Use it! by yakatz · · Score: 3, Informative

    And Facebook uses PHP which does support checking the difference between NULL and 0: http://php.net/manual/en/types.comparisons.php (look at the table of Strict comparisons with ===

  7. Re:NULL is there. Use it! by bsolar · · Score: 2

    1) That specific value is a number

    No, it's not. Don't take my word for it: play with SQL and realise that NULL doesn't behave like a number when used in operations and functions.

    2) It's not always unambiguous, hence this story.

    It's definitely unambiguous. Again, don't take my word for it, take e.g. a TINYINT and try to figure out which of its possible values is ambiguous with NULL. (Read: SELECT x = NULL results in True, hint: there is no such value).

    The story is *not* about NULL having an ambiguous representation: it's about the programmer *not* using NULL to represent the concept of "missing information" (which is exactly why it exists in SQL) and instead (ab)using a specific numerical value.