Future plans to allow saving an 'invalid date'?

At this time, there is no way to save an ‘invalid date’. What I do is to either set the date field when data is available or I unset the field. When you look at the object, the date field may or may not exist.

Although this works very well, it means more work for people using strong typed languages. I have never used the Javascript driver for MongoDb, but from what I can see, it is trivial to store either a valid date or a null date.

I love MongoDb, it is very unlike any other datatabase that I’ve worked with. In other databases, you can store a ‘blank’ date or a value that represents an ‘invalid date’. When that value is read, you know that you’ve got a blank date.

I’m using version 4.2 at the moment and I’m wondering if there are plans to allow the storage of an ‘invalid’ date in the future. This is not a request, I ask out of curiosity. Thank you.

Hello @Billy_Zee ,

Welcome back to The MongoDB Community Forums! :wave:

MongoDB stores the date in BSON format. May I ask what you meant by “invalid date”? Can you also share some examples of the same?

MongoDB supports a flexible schema design which gives you data-modeling choices to match your application and its performance requirements. In your case, you can either add the date or leave it as it is.

Can you please provide more clarification around your requirements so that I can assist you better?

Lastly, MongoDB version 4.2 is no longer supported so I would recommend you to upgrade to at least MongoDB version 4.4 which is in support till Feb 2024. For more information regarding MongoDB Software Lifecycle Schedules, kindly visit


Hello Tarun,

I currently use a solution that I’m sure is commonly used by MongoDb users which is to either $set a date provided and to $unset when it is not provided.

On the SQL systems that I’ve worked with, an ‘invalid’ value is specified and I’ll explain why this is helpful further down below. Please note that the solution to set/unset works perfect but just means more work for people working with a strongly typed language because you must declare the data type, e.g.: bsoncxx::types::b_date which means that if I store null, we obviously will get a compiler error. To avoid this, we must check to see if the date has been provided or not, then set/unset accordingly.

Now back to your question to me, an ‘invalid date’ would be a 64 bit integer value that is stored when say no date has been specified. That value would have meaning to the database that no date has been stored, just like $unset. The only difference is that if we $unset, there is no field (which is perfectly acceptable). If we stored an ‘invalid_date’ value, we’d have a field with a value representing ‘invalid date’ (or no date supplied).

Having the ability to store an ‘invalid_date’ would allow users using a strong typed language to use the same syntax to save a date without the need to have special logic to set/unset the field.

This may not be a concern for Javascript developers using MongoDb because I am assuming that the can either set/unset like I currently do (using the mongocxx driver) or they can simply save ‘null’ to MongoDb if they so chose to do (unlike users of strong typed languages).

As you can see in the snippet below, I can use the following line of code to handle an empty string or a string with somebody’s name:

kvp(kfirstName, firstName)

If we had the ability to store an ‘invalid date’, we could use identical syntax to do the same with a strongly typed language.

Since MongoDb does not allow you to store the concept of an invalid date, I do this:

auto publish = getTimestamp(kpublish);
if (!publish.is_not_a_date_time()) {
	setDoc.append(kvp(kpublish, to_b_date(publish)));
else {
	unsetDoc.append(kvp(kpublish, ""));

As you can see, I cannot handle MongoDb dates as easily as I can handle string data. I have to do some checking to set/unset.

This is perfectly fine and acceptable for me since it works exactly as it should. I just wanted to be sure that the newer versions of MongoDb had not changed in this specific regard.

P.S. In my humble opinion, I do think that not storing a ‘null’ date really is best not only because you store less data, but my guess is that indexing benefits by simply not dealing with ‘null’ values.