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.
Lol. I love your sarcasm.
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.
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).
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
PHP is ok, its the humans that use it which have all the problems.
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".
But if NULL is -123 then it's just as bad as "default -123", and if you treat NULL as not being equal to any representable number, then you need to use an untyped language like JavaScript because in typed languages every possible bit pattern for int32, uint32, etc already corresponds to a number. No bit pattern is available for something else.
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 ===
Well except in Oracle databases. Try teaching it the difference between an empty string (I don't have a middle name) and NULL (middle name is unknown).
If you treat NULL as 0, then I hope you are not a developer.
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.
Did you know that computers store all values in BINARY? That means ZERO or ONE. Even your off topic, pedantic rant is just ZEROES and ONES to the COMPUTER.
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.
in any given data structure, you can use a bit vector to represent whether a value of a particular index is null or not. you don't use the "value itself" to represent null... that's just boneheaded (e.g. 0 is a valid number...).
I don't understand people who prefer to use magic numbers over NULL, but there appear to be many.
Because MySQL and its helpful, default options.
[...] 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
So which number do you use to represent NULL in your database? (Hint: it's a binary number)
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
Maybe structures only need a bit vector, but now each variable needs another corresponding "isNull" variable, and each time you do result = foo.x + 12 you have to remember to also do something like resultIsNull = foo.nullBitVector & 0b000001000;
Seems much more boneheaded to me.
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.
What a load of crap.
You don't care how the processor handles NULL, because any reasonable programming language not specifically made for low level systems programming will not even let you perform unreasonable operations on NULL. And why is that so? Because it's a shitty idea to allow it, as evidenced in TFA, that's why, which was @nullchar's argument in the first place.
And no, higher level languages don't just hide the problem away, they actually solve it.
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.
This.
Incorrect, the PHP time functions work fine.
Website Just Down For Me? Find out
Party like it's 1999!
Happy New Year!
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.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
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.
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 handling of NULL.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
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.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
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.
I dont know what specific database platform your talking about. But with sql server a null value in a nullable column isnt actually stored in the field. Sql server keeps a separate bit (packed together with other nullable columns into one or my bytes) that indicates "this column+row's value is null".
Thats how sql server stores a null for an in or any other type of column. None of the possible values for an int are used. None of the bits within the int are used. Its a separate bit per row, per nullable column, packed in to bytes alongside other nullable columns.
C# nullable ints are similar. The null value is not in the int. It uses a separate bit as part of the struct to indicate if the value is actually null.
And if I as someone who doesn't understand any language other than english read a french text I will occasionally encounter a word that is the same as an english one. It doesn't mean that the intended meaning of that word in the french text is the same as the english word.
The french language isn't broken or stupid, I am for attempting to interpret the data in the way that I am.
A magic number is a unique value with unexplained meaning. Since NULL in relational databases has a distinct and well-known meaning, it is not a magic number.
And that's exactly the problem with PHP - far too easy to fall out of the abstraction and get "undefined" behaviour.
No doubt you'll tell me that's a feature now ...
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!
ADO returns null dates as null.Where have you seen the conversion you're talking about ?
#define NULL 0
is a perfectly valid definition of NULL according to ANSI C.
A lot of databases actually use additional bits (one per column) to mark whether the content is null or not. Oopppps... there goes your entire argument.
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
And that is usually a good idea. But where I come from, bits are numbers.
Where I come from, bits can also be strings. Or whatever kind of information you'd like to store, like, for instance, "no data is defined for this particular variable". Many, many languages other than SQL implements an "undefined" state for variables, even primitive types.
Edit: actually, nevermind. I see from your other comments that you have a deep non-understanding of NULL, undefined and similar concepts as employed in programming languages, or that you are obtuse to the point of trolling. If the first is the case I would read up a little before engaging in further discussion if I were you.
Maybe, but then one shoudl probably consider PHP the mother of all enablers
Having read all of your posts in this sub-thread, it's hard to be sure whether you're being intentionally obtuse or argumentative. Everyone else seems to have given up, so I'll give it a shot. This is long, so there's a TL;DR at the end.
Sorry, your database, and it's NULL entries, are nothing more than magic numbers.
In the context of a RDBMS, NULL is a concept distinct from the set of values which can be properly represented in some DB field. How the NULL concept is actually represented depends on the RDBMS implementation. For integer fields, NULL might be represented by a sentinel value (or magic number) in the field itself. DBase worked that way (at least through DBase 7), though it didn't use 0 as the sentinel value. Alternatively, the field might use a reserved tag bit. Another approach is to have a bit array, one bit per field, as part of the row header, where each bit indicates whether the respective field is NULL.
All of that is orthogonal to how a NULL DB field gets presented by some API for use in application code.
I'm discussing NULL in a database as related to the story...
From the first article linked in TFS:
The precise explanation behind this timestamp kerfuffle remains unclear. However, another developer thinks he knows what happened. As Microsoft engineer Mark Davis explained on Facebook...
You and I don't actually know whether NULL or zero or something far less likely is being stored by FB for the date, unless you have access to information not linked from TFS. So you're not talking about what you think you're talking about. Since the crux of this whole sub-thread is NULL field values, let's set aside the other possibilities. If we assume for this discussion that FB is storing NULL, then you still don't know if that's represented as a magic number unless you know what DB FB is using for this, and that they haven't modified it for their own use cases. Finally, unless you know exactly how they retrieve that data, e.g. by PDO, and also that they haven't modified that for their own use cases, you have no idea how NULL values appear at the application level (some possibilities later).
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.
Most everyone else is discussing NULL as a generally consistent concept across most any RDBMS. You seem to be getting hung up on implementation details, and further seem to be conflating the possible representations of NULL field values for the RDBMS, with the possible representations of NULL field values as they are presented to application code, typically via some API or framework, e.g. ODBC, PDO, or ADO.Net (the last of which FB is certainly not using).
I assume FB is using PHP, presumably HHVM. I've not used PHP since 3.0 and have no experience with HHVM. However, the problem of dealing with DB NULL values cuts across languages, and there is more than one DB API available for PHP.
You baldly asserted that NULL entries are nothing more than magic numbers, but that is not necessarily the case at the application level, then you backtracked a little to limit your assertion to the FB database. An API might automatically convert NULLs to some "reasonable" value, such as an empty string or zero, in which case the effect is exactly as you state. However, an API might present NULL values as a semantic analogue where the language (as with C# nullable types) or library (as with OLEDB and classic VB or any other language which supported OLE variant types) has built-in support for an approximation of the RDBMS concept of NULL. It's possible, though I don't recall ever seeing it, that an API might present field values as data types which act as workalikes for standard data types in the application programming language, but throw an exception
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."