Django 1.5.1: ORA-01843: not a valid month

Skip to first unread message

Carsten Fuchs

Apr 10, 2013, 10:50:04 AM4/10/13
to Django users
Hi all,

last night I updated our productive system from Django 1.4.4 to 1.5.1,
and we're now seeing error "ORA-01843: not a valid month" when saving data.

OS is 32-bit Ubuntu 10.04 (fully updated)

Oracle database is on a remote host, version 10g Enterprise Edition

This is the model definition that we're seeing the problem with:

class Erfasst(models.Model):
id = models.AutoField(primary_key=True)
key = models.ForeignKey(Mitarbeiter, db_column='key',
to_field='key', on_delete=models.PROTECT)

datum = models.DateField()
status = models.ForeignKey(Status, db_column='status',

anfang = models.CharField(max_length=8, blank=True)
ende = models.CharField(max_length=8, blank=True)
pause = models.CharField(max_length=8, blank=True)
faktor = models.SmallIntegerField(choices=[(60, "1.0"), (90,
"1.5"), (120, "2.0")], default=60)

bonus_url = models.DecimalField(max_digits=5, decimal_places=2,
null=True, blank=True, verbose_name=u'Bonus-Urlaub')
bemerkung = models.CharField(max_length=40, blank=True)
bereich = models.ForeignKey(Bereich, null=True, blank=True,
zustand = models.SmallIntegerField(db_column='flag')

approved_by = models.ForeignKey(User, null=True, blank=True,
on_delete=models.PROTECT, related_name='approved_set')
approved_at = models.DateTimeField(null=True, blank=True)

last_user = models.ForeignKey(User, null=True, blank=True,
last_modified = models.DateTimeField(auto_now=True, null=True)

And this is an example from `./ shell` that reproduces the error:

>>> from Lori.models import *
>>> st = Status.objects.get(id=1)
>>> ma = Mitarbeiter.objects.get(key="F200")
>>> e = Erfasst(key=ma, datum=date(2013, 12, 12), status=st,
bemerkung="TEST CF", zustand=1)
Traceback (most recent call last):
File "<console>", line 1, in <module>
"/usr/local/lib/python2.6/dist-packages/django/db/models/", line
546, in save
force_update=force_update, update_fields=update_fields)
"/usr/local/lib/python2.6/dist-packages/django/db/models/", line
650, in save_base
result = manager._insert([self], fields=fields,
return_id=update_pk, using=using, raw=raw)
line 215, in _insert
return insert_query(self.model, objs, fields, **kwargs)
"/usr/local/lib/python2.6/dist-packages/django/db/models/", line
1661, in insert_query
return query.get_compiler(using=using).execute_sql(return_id)
line 937, in execute_sql
cursor.execute(sql, params)
line 717, in execute
utils.DatabaseError(*tuple(e.args)), sys.exc_info()[2])
line 710, in execute
return self.cursor.execute(query, self._param_generator(params))
DatabaseError: ORA-01843: not a valid month

I also attach a full debug output page with additional details from our
live site, showing the same error.

Some observed paradoxes:

- I didn't receive any of the usual error e-mails that normally are
reliably sent whenever an application error like this occurs. The
attached page was generated by temporarily setting `Debug = True`.

- On a second production system, which is also Ubuntu 10.04, but
64-bit x86_64 with cx_Oracle-5.0.4 (and the exact same Django version
1.5.1 and exact same application code, connecting to the same database),
this problem cannot be reproduced. Both in the shell as well as in the
application, everything works normally. The same is true for my
development system, which has a local database instance and
cx_Oracle-5.0.3, working normally.

It seems that the same problem has been reported at,
but unfortunately I'm not able to derive any progress or solution from it.

What can we do?

I consider downgrading to Django 1.4.5 on the affected system, as I'm
unfortunately unsure how to best proceed with debugging and/or fixing this.

Any help would very much be appreciated!

Thank you very much, and best regards,

Dipl.-Inf. Carsten Fuchs

Carsten Fuchs Software
Industriegebiet 3, c/o Rofu, 55768 Hoppstädten-Weiersbach, Germany
Internet: | E-Mail:

Cafu - the open-source game and graphics engine for multiplayer 3D action
DatabaseError_at _erfassen_bereich_12_.htm

Carsten Fuchs

Apr 10, 2013, 11:21:03 AM4/10/13
Am 10.04.2013 16:50, schrieb Carsten Fuchs:
> I consider downgrading to Django 1.4.5 on the affected system, as I'm
> unfortunately unsure how to best proceed with debugging and/or fixing this.

I just found out that when we

- downgrade cx_Oracle to 5.0.3, the problem does not occur,
- upgrading cx_Oracle to 5.1.2 brings the problem back.

So as was mentioned in the Stackoverflow post, this is likely a problem
in cx_Oracle rather than Django...

Best regards,

Carsten Fuchs

Apr 12, 2013, 12:53:11 PM4/12/13
Am 2013-04-10 17:21, schrieb Carsten Fuchs:
> So as was mentioned in the Stackoverflow post, this is likely a problem in cx_Oracle
> rather than Django...

Well, I probably shouldn't have said this, because this problem did not occur with
Django 1.4.x, and more importantly, I wonder what should be the next step?

Should I file a bug for Django, re-post at the django-developers list, or try to contact
the cx_Oracle developers?

Best regards,


Jan 30, 2014, 3:01:01 PM1/30/14
if you upgraded django and the issue begins, wouldn't that point to the version of django? one would think so.
however , rolling back to the older version of cx_Oracle fixes the issue.
conclusion would be:
  it seems to be an issue when django > 1.4 AND cx_Oracle > cx_Oracle 5.0.3!
This problem does not occur with Django 1.4.x or cx_Oracle 5.0.3!

we have the problem also.
we can't rollback to the old cx_Oracle b/c it was buggy for us and we are told to upgrade to django 1.6.

has anyone got a solution? :) thanks
Reply all
Reply to author
0 new messages