Epoch Time Bug Causes Facebook To Congratulate Users On 46 Years of Friendship (gizmodo.com) 108
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."
Oblig (Score:5, Funny)
Re: (Score:3)
At least facebook's logon system works.
Re:Oblig (Score:4, Funny)
and you see that as a good thing?
Re: (Score:2)
Also, another fail in this whole slashdot in 2016 is that this news was all over everywhere else. I keep seeing news fit for non nerds on here that made its way to me hours, days, or even weeks earlier on other sites.
Yes, that's how Slashdot works. It's pretty difficult to REpost a story if it hasn't been posted for the first time yet.
Re: (Score:1)
Indeed and, as a bonus, that was one of those epiphany moments (not a big one, however) were I realized why I sometimes saw that date in the past. I figured out why it's always that date for certain things (like when you install a forum and they have the initial welcoming post) and I hadn't known that before. I am also guessing that that's when the date officially began counting up because, as I understand it, it's just counting seconds since the official beginning date. That's a presumption on my part and
But how is this possible? (Score:1)
We have so many women graduating college, and early STEM education, and experienced workers training their H1-B replacements, how can there be any coding errors?
Insurance companies vote GOP and you will get that (Score:2)
Insurance companies vote GOP and you will get that.
Not an Epoch bug (Score:5, 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.
Re: (Score:3)
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 ..."
Re: (Score:3)
Re: Not an Epoch bug (Score:1)
Rust has the Option enum preisely for that.
Re: Not an Epoch bug (Score:2)
This is a database value so it most likely only accepts valid date integers. False is not an integer.
Re: (Score:3)
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 20
Re: (Score:2)
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.
In the real world, yes. On Facebook, no.
NULL is there. Use it! (Score:4, Interesting)
I don't understand people who prefer to use magic numbers over NULL, but there appear to be many.
Re: (Score:1)
I don't understand people who prefer to use magic numbers over NULL, but there appear to be many.
Last I checked, NULL is just a magic number (usually zero).
Re: NULL is there. Use it! (Score:1)
NULL should never be zero. If you treat null's as zero's it is just as bad as "default 0" and then using it in a date calculation.
Re: NULL is there. Use it! (Score:4, Informative)
Re: (Score:2)
Yes, but unless explicitly checked like that PHP will happily convert NULL to 0 for you without blinking an eye. It's just one of the many many landmines that PHP has for you to step in if you're not extremely careful programming in that crap language.
Re: (Score:2)
Awe, thats cute, you're one of those spoiled kids that doesn't know how the computer works because you use high level languages that abstract everything from you.
To store 'NULL' you have to encode it SOMEHOW for the processor to have any usefulness to it, that encoding could ALWAYS have another meaning. Processors have absolutely no concept of NULL, so NULL is effectively ZERO to any programmer who actually understands how computers actually work.
Sure, in Java, .NET and many other high level languages, the
Re: (Score:2)
Thank you for proving my point even though you don't understand that you did so.
Re: (Score:2)
0 is a valid number only when representing numbers ... in which case you actually use an additional number to represent that the first value is or isn't null ... that additional number (or bit or whatever) immediately has a duplicate meaning since you're repurposing one value for another (encoding it).
In both instances, you're still using zero (or not zero) to represent null, you're just pretending you're not because you've encoded it.
In C like languages, NULL == 0 is that encoding. int i = NULL makes you
Re: (Score:2)
in C and C++ null is not really encoded as 0, but it is represented that way syntactically. int i = NULL will give you a 0-encoded NULL. void * i = NULL need not, though. Of course, most C implementations do encode null pointers as 0, but not all.
Re: (Score:2)
Awe, thats cute, you're one of those spoiled kids that doesn't know how the computer works because you use high level languages that abstract everything from you.
To store 'NULL' you have to encode it SOMEHOW for the processor to have any usefulness to it, that encoding could ALWAYS have another meaning.
Who gives two shits about what the processor is doing? The processor isn't the interface or the logical representation actual people are managing.
Whether databases use separate bit fields or simply reduce published range of a datatype by 1 to make physical room for expressing 'NULL' who exactly cares? Why is it relevant at all?
In systems which properly express NULL values NULL is NULL, NULL is not 0 ever.
Processors have absolutely no concept of NULL, so NULL is effectively ZERO to any programmer who actually understands how computers actually work.
Completely irrelevant.
Re: (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: (Score:2)
[...] And also because NULL should be NULL, not a value that might be valid to other types of code.
Blah, blah, blah, I don't care how you fancy it up, everything the computer does is dealing with numbers. NULL is just another binary number any way you slice it, and it will be a valid number in code if you're not careful keeping track of which data is NULL and which is the number used to represent NULL.
If you disagree, please by all means tell how *you* represent NULL without using some combination of ones and zeros.
Re: (Score:1)
Every participant in this thread with the exception of you and Bitzstream understand the context of this discussion relates to NULL in a database. How the two of you consistently fail to grasp this concept is surely exhausting to all other posters. Yes, we understand binary. That has nothing to do with a programmer at Facebook writing a buggy SQL query.
% select username from users where brain = 0;
username
------------
(0 rows)
% select username from users where brain IS NULL;
username
-----------
Re: (Score:1)
Sorry, your database, and it's NULL entries, are nothing more than magic numbers. I'm discussing NULL in a database as related to the story, and you're discussing NULL in a database that isn't in the story but pretending it is because that's the database you're familiar with.
Re: (Score:2)
And that is usually a good idea. But where I come from, bits are numbers.
Re: (Score:2)
You mean someone didn't do ISNULL() on the returned value and let the connector interpret ...
That makes both the connector and the developer stupid :) The connector should have returned NULL or an error/exception.
Just for reference, NULL behaves like that in any sane language, excluding C/C++ due to its low level nature, though the compiler will effectively fix that flaw in the case of most processors where it can do so intelligently since page 0 is almost universally 'protected' against reads AND writes b
Re: (Score:2)
Re: (Score:1)
So which number do you use to represent NULL in your database? (Hint: it's a binary number)
Re: (Score:2)
Hint: the specific internal representation is absolutely irrelevant in the context of the discussion: the point is that whatever representation is used for NULL, it's a different representation from any other valid value. Yes, this means that e.g. if you have in-DB a nullable TINYINT (1 byte number), you have *more* information than what is representable in a C or Java variable of type 'byte' (primitive).
How you'll need to define your programming data model to accurately map all informations you read from t
Re: (Score:1)
How you'll need to define your programming data model to accurately map all informations you read from the DB is a completely different issue and doesn't change the fact that the DB *does* provide a specific value which represent unambiguously the concept "information is unknown".
1) That specific value is a number
2) It's not always unambiguous, hence this story.
Re: (Score:3)
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 "m
Re: (Score:1)
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.
So if I take your SQL database, and read it with a C program that prints the file bit by bit as ones and zeros, at some point your magical non-numerical NULL entry will output something other than a number?
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.
Yeah, but if you read the database with a different program that has a different idea of which number means NULL then all your NULL entries are suddenly numbers. And maybe someone thought they'd be clever and store data more efficiently by using only 8 bits to store their TINYINT, then messed it up their
Re: (Score:2)
Yeah, but if you read the database with a different program that has a different idea of which number means NULL then all your NULL entries are suddenly numbers.
Database access interfaces include management of concept of NULL even if a suitable analogue of the concept is not directly supported by underlying programming environment. Being lazy and or using shitty APIs have predictable results including committing totally preventable errors. NULL exists to prevent exactly this type of failure from ever occurring.
And maybe someone thought they'd be clever and store data more efficiently by using only 8 bits to store their TINYINT, then messed it up their handling of NULL.
There always seems to be an infinite array of excuses for fucking up and then being surprised when hit with equally screwed up outcomes. "being clever" in
Re: (Score:2)
Null is probably stored as a flag, not a number. The flag says that the number value is ignored. It could be a high bit in a numeric value making it.out of range, and that's definitely not zero. But its not a numeric value, its a flag.
How about you look at some open source databases or read Wikipedia or something?
Re: (Score:2)
So your computer uses trinary, one, zero, NULL? My computer would store a flag bit as a number, either one or zero.
Re: (Score:1)
Hmm... Would it store it as a 1 or 0 or would it store it as a 00001 or 00000? 'Cause the whole (the 1 or 0) might be represented in binary and thus take more than a single bit to represent the whole, no?
Re: (Score:2)
In C this is true NULL is defined as 0. However, in SQL the semantic of NULL is "value not set".
Re: (Score:2)
Close.
In C a true NULL is defined as a cast FROM integer 0 to a pointer. The difference in definition is that the reverse is not true, and casting NULL TO an integer is implementation defined.
Re: (Score:2)
Re: (Score:2)
According to C11 in the section for pointers (6.something), null is defined in stddef.h as
#define NULL ( (void *) 0)
If some platform defines it otherwise then it goes against the C standard.
That doesn't mean you're not right, it just means that the platform was not following the standard correctly.
Re: (Score:2)
Re: (Score:2)
No. Sorry I just looked at C11 as an example. The text is unchanged from C99.
ANSI C on the other hand is a bit more difficult.
4.1.5 shows the standard defines in stddef.h and has written:
" The macros are
NULL
which expands to an implementation-defined null pointer constant;"
That is interesting because on the one side it says implementation-defined but on the other hand section 3.2.2.3 on pointers states:
"An integral constant expression with the
Re: (Score:2)
Re: (Score:2)
Well if you want to talk pre-1989 standardisation then all bets are off. A lack of a standard by definition means people can do whatever the heck they want :-)
Re: (Score:2)
He just smiled and said, "It won't."
From that I learned to recognize things that won't likely change in the future, in contrast to things that will.
Re: (Score:2)
Those problems extend way beyond programming. We take all sorts of things for granted as something that won't change in the future :-) That's why it's so important to quote the year after a standard when you reference it. It's a wonderful lesson of arsecovering because even the most obviously established of standards can change.
Re: (Score:2)
It's a wonderful lesson of arsecovering because even the most obviously established of standards can change.
That's true, but I still feel perfectly comfortable using 0 as NULL.
Things that are more likely to change need more attention given to make them flexible.
Re: (Score:2)
void *a = 0;
int b = (int)a;
if(b==07777){
printf("true\n");
}
Re: (Score:2)
Certainly and that could be true by all standards because while void *a = 0; is defined in the standard, int b = (int)a; is implementation specific.
All bets are off.
Re: (Score:2)
If you treat NULL as 0, then I hope you are not a developer.
Obviously. You need to treat it as ValueOf(NULL), since it might be zero in one program or some other number in another.
Re: (Score:2)
Re: (Score:2)
Agreed that using NULL is typically better than using magic numbers, but NULL isn't a perfect solution either. It has different semantics in different languages, and comparisons are often confusing and/or undefined.
Use a flag instead.
Re: (Score:2)
NULL should be combined with a flag. NULL gives you the fast-failure (nothing will work, because nothing should). The flag tells you why.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
A millions ways to code it correctly, but only a few architectural decisions that would prevent this particular bug. The decision to give a fake value to an unknown is wrong before the first line of code has been written.
Re: (Score:2)
NULL is intended for checking pointers, not for integers. In this case, 0 is correct.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
NULL is 0 on many systems. If you're in an extremely high level language and you don't care about how much space your database takes up, then you have types stored along with values. But if you're using a low level language down below for speed purposes then using NULL won't fix the problem.
Where what? (Score:1)
Who would store a numeric timestamp as a varchar? Certainly storing it as a numeric value type would be more appropriate.
Re: Where what? (Score:2)
That and while is normally used for loops... 'IF' would have been more appropriate for his example. But since we all got his point the example served its point.
Re: (Score:2)
That and while is normally used for loops
Err, yes, but this is a SQL "WHERE", not a "while".
I guess it's been a where since you did any SQL ;)
Re: (Score:2)
Yah; I guess my own language basis got in the way of reading comprehension. Can't ever think of a time of writing a 'where' statement, but in an SQL context that makes perfect sense.
You want my age? (Score:1)
Doesn't everyone who is asked for a birthday they don't want to enter use 1/1/1970 :-)
Re: (Score:2)
Has UNIX ever considered the poor people who actually were born on 19700101? And who have to prove it to every single damn webpage out there?
Re: (Score:2)
Has UNIX ever considered the poor people who actually were born on 19700101? And who have to prove it to every single damn webpage out there?
Unix time was (occasionally is) represented by a 32 bit signed integer, meaning both zero and negative values can be stored just fine.
Only people who are 115 years old or more would have any problems on those old unix systems.
Specifically dates prior to 1901-12-13.
However even that limitation has been fixed roughly a decade ago when "time_t" was modified to be a 64 bit signed integer.
Negative values in 64 bits is supposed to be a couple hundred billion years (or so I've been told, I don't have that many fin
Re: You want my age? (Score:2)
You have 32 fingers?
Re: (Score:2)
31 fingers actually. I lost the 32nd in the great Canadian bacon catastrophe of '78.
(uid,uid,date) (Score:2)
There's a threeple only an NSL could love.
Birthdays too perhaps? (Score:1)
But it's not actually my birthday. (Nor do I display my birthday on FB).
PARTY (Score:2)
Party like it's 1999!
Happy New Year!
Re: (Score:2)