Slashdot Mirror
Epoch Time Bug Causes Facebook To Congratulate Users On 46 Years of Friendship (gizmodo.com)
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."
Epoch fail.
Obliteracy: Words with explosions
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?
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.
I don't understand people who prefer to use magic numbers over NULL, but there appear to be many.
Last post!
Insurance companies vote GOP and you will get that.
Who would store a numeric timestamp as a varchar? Certainly storing it as a numeric value type would be more appropriate.
Doesn't everyone who is asked for a birthday they don't want to enter use 1/1/1970 :-)
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.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
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.
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.)
Check again. We're talking about a database: "the answer is unknown" is definitely not the same as "the answer is known and is 0". NULL exists as concept exactly to differentiate between the two. From the summary it's pretty clear the answer is not known, so it should have been represented with NULL.
There's a threeple only an NSL could love.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
In C this is true NULL is defined as 0. However, in SQL the semantic of NULL is "value not set".
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, there is an object that actually represents null that abstract the problem away from your code, but it remains, just hidden from you.
So before you talk about 'how it should be', keep in mind that what your CS professor taught you ... isn't actually how the real world works.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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
There are a million ways this could have been coded 'correctly'. Please let us not start going through them all.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
I had a couple people on FB wish me happy birthday today.
But it's not actually my birthday. (Nor do I display my birthday on FB).
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 ===
NULL is intended for checking pointers, not for integers. In this case, 0 is correct.
Checking pointers in a relational DB? We're talking about this NULL.
Zero is obviously not correct in this case. Null semantics vary by language. Even if writing this in C, you'd want some semantic that would let a database query answer "I don't know that" rather than zero.
[...] 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.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
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.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
Thank you for proving my point even though you don't understand that you did so.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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 stupid, not the language, because you just used a shitty encoding for that particular data type, and caused yourself a world of trouble.
Just because you're incapable of seeing the pattern your using is the same doesn't mean it isn't.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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 by operating systems that use MMUs or MPUs, and the compilers will warn or error when using NULL on a integer type since that is indeed confusing and value types can't actually ever be NULL.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
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 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".
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.
Incorrect, the PHP time functions work fine.
Website Just Down For Me? Find out
Party like it's 1999!
Happy New Year!
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?
So your computer uses trinary, one, zero, NULL? My computer would store a flag bit as a number, either one or zero.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
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.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
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
------------
Bitzstream
penguinoid
(2 rows)
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.
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.
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.
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 particular is responsible for quite a variety of sad/amusing screw ups.
I understand bugs happen yet there is no excuse for this type of failure any more than there is an excuse for SQLi. It is entirely preventable. These things only happen when coders do things they should know to be wrong at the time they are doing them. They took a shortcut and it burned them. There is no excuse or justification.
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?
"So long and thanks for all the fish."
Are you perhaps thinking of C? Its meaning of NULL is nothing like SQL's.
NULL should be combined with a flag. NULL gives you the fast-failure (nothing will work, because nothing should). The flag tells you why.
Last post!
And that is usually a good idea. But where I come from, bits are numbers.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
That's weird, I didn't think NULL even had to be 0. I remember reading about some platform where NULL actually wasn't zero.
"First they came for the slanderers and i said nothing."
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.
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.
Last post!
oh, it was defined recently. Interesting.
"First they came for the slanderers and i said nothing."
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 value 0, or such an expression cast to type void * , is called a null pointer constant."
that doesn't leave a lot of room for the implementation to define.
And then yet when you go down to casts in section 3.3.4 you get:
"A pointer may be converted to an integral type. The size of integer required and the result are implementation-defined. If the space provided is not long enough, the behaviour is undefined. An arbitrary integer may be converted to a pointer. The result is implementation-defined."
So if the explicit declaration in section 3.2.2.3 takes preference over the parts that talk about it being implementation defined then it is consistent with C99 and C11, but I can see when going through the original 1988 text how it could create confusion.
C99? I'm talking old, bro
"First they came for the slanderers and i said nothing."
Reading the sections of the ANSI C standard you copied, it seems carefully written so that NULL can be defined to be any value on a given platform......however the idiom of using (void*)0 to represent a null must be preserved. So you could have code like this that evaluates to true:
void *a = 0;
int b = (int)a;
if(b==07777){
printf("true\n");
}
"First they came for the slanderers and i said nothing."
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 :-)
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.
One of my earliest memories as a professional programmer was telling another, more experienced coworker, "Don't use 0 instead of NULL! There will be problems if it changes in the future!"
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.
"First they came for the slanderers and i said nothing."
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.
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.
"First they came for the slanderers and i said nothing."