View Full Version : MysqlDateField: prevents DateField to transform 0000-00-00 to 1970-01-01

22 Jun 2008, 1:28 AM
a lot of mysql databases has lots of 0000-00-00 values into date fields.
this happens when we try to save '' (empty string) into a date field in mysql.

the problem is that Ext.form.DateField transform this value to 1970-01-01.

this very very simple extension prevents this transformation:

Ext.ux.form.MysqlDateField = Ext.extend(Ext.form.DateField, {
parseDate : function(value){
if (value=='0000-00-00') {
value = null;
return Ext.ux.form.MysqlDateField.superclass.parseDate.call(this, value);
Ext.reg('mysqldatefield', Ext.ux.form.MysqlDateField);

The usage is equal to basic DateField, for example:

new Ext.ux.form.MysqlDateField({
format: 'Y-m-d'

22 Jun 2008, 11:31 AM
The client API is an interesting place to fix a DB design problem.

Why not just fix the SQL INSERT abstraction at the DB server instead?

What was the motivation, driving factor, or use case that led to the decision to push this fix all the way out to the client?


23 Jun 2008, 4:33 AM
I agree that this should be prevented when inserting the data in the database, rather then fixing it in the client gui.

23 Jun 2008, 1:52 PM
Uhm..dudes, I think this plugin is referring to data selected from the database, not being inserted into it. Having 0000-00-00 in the DB is perfectly valid in some systems. But, it would seem, that is not valid to Ext JS.

If thatis indeed the problem, I believe this bit of code bridges that gap nicely.

23 Jun 2008, 2:28 PM
I guess I read too much into "when we try to save '' (empty string) into a date field in mysql".

Besides - Dude - its a fairly common computer science principle to attempt to fix format issues at the format source. The allegory would find us writing ExtJS plug-ins to deal with compressed binary MyISAM files otherwise.

My question was about what the use case was. Perhaps there was use of a SOAP service returning empty date strings. In this use case they may have no control over the server, hence a very reasonable purpose to employ such a tool.

My question about what motivated the plug-in was reasonable - Dude.

Best regards,


29 Jun 2008, 11:16 PM
I think it's the right place to fix '0000-00-00' to not display as '1970-01-01'.

If it's a bug/or feature/ in datefield, then it should be fixed on this level.

For me, 0000-00-00 is perfectly valid for 'no date' (yes, I use null, but this doesn't makes it less valid). Not mentioning the possibility to work with someone else's database, not your own.

Gerard Pastis
26 Jan 2011, 3:10 AM
In a more "hardcore" mode:

// Security Closure
(function() {
// Transform 0000-00-00 date to null
var originalparseDate = Date.parseDate;
Date.parseDate = function() {
if (arguments[0] && arguments[0] == '0000-00-00') {
arguments[0] = null;
//call the original function
return originalparseDate.apply(this, arguments);